Wt

Hey Koen,

If the WAnchor has a null WLink, it can simply render without an href attribute at all, which should not have any problems at all in the first place and it is valid for an tag to lack an href attribute. That part I think we are in agreement with? The only thing to be careful about is to make sure that empty href attributes cannot be set, i.e.:

<a>Link</a> // OK
<a href>Link</a> // Problem
<a href="">Link</a> // Problem
<a href="/items">Link</a> // OK

Now the second part of this topic and the only actual issue as far as I am aware, is that some links require href="#" to work properly in certain situations and environments as I noted above.

I believe I have a solution but first I need to ask: is '#' by itself an invalid internal path (you need at least #/ I think)? If that is true, we could check if the WAnchor's WLink is comprised solely of #, then its click event could be set to call e.preventDefault() so the browser won't react to a navigation event and mess up internal paths (but should still be able to participate in Wt event handling).

What are your thoughts on this approach? I will also do more testing later today with needsUrlResolution = false as you noted.

Hey Jake,

Setting needsUrlResolution to false will make this work.

As to the '#' problem, we should first find out if it is actually Internet Explorer which would require the href attribute in the first place, otherwise it is effectively not a problem.

Regards,

koen

Does the following look right to you?

needsUrlResolution = link_.isNull() ? false : (!app->environment().hashInternalPaths() && href.find("://") == std::string::npos && href[0] != '/');

Hey Jake,

That looks correct (although I will refactor things a bit since link_.isNull() really is a different code path)

I've looked it up: this is a change since August last year, but I cannot trace any reasoning for it. So I am inclined to accept the proposal to drop the workaround (after the final Wt 3.2.2 release).

Regards,

koen