#101 Browser: Clicking on an anchor link does not raise events

[gnosygnu]

This ticket arose from two separate defects:

• Back and forward does not work properly when clicking on Table of Contents links: https://sourceforge.net/p/xowa/discussion/defects_resolved/thread/3757d382/

• Address bar should update with name of link:
  https://sourceforge.net/p/xowa/discussion/defects_resolved/thread/aff569dd/

Unfortunately, this turns out to be fairly difficult. The SWT browser does not raise an event for anchor links. In other words, clicking on <a href='#a' /> does not notify Java at all. It seems to be consumed entirely in either SWT or the browser.

I can hack around this by creating a non-anchor link. For example

• <a href='/wiki/Page#a' />

• <a href='/#/a' />

Both of these would fool the browser into thinking they're not an anchor link. The first is slightly more standard, but the second has the advantage of being much shorter.

There are disadvantages:

• Non-standard HTML MediaWiki generates anchor links with "#a", and XOWA would be generating one of the above. Note that this affects reference links as well as TOC links.

• Significant code change: A lot of anchor-handling code would have to be changed (along with their tests)

• Invalid in View As HTML mode: Neither approach would work if a page were exported using "View as HTML" (I doubt any one really uses this, but still)

I'm going to table this as a PFE for now. If anyone feels this is useful behavior, please comment below, and I'll reassess for a near release. Otherwise, it may be a while.

[gnosygnu]

While writing up a bug report, I discovered that SWT does raise anchor click events -- just in an unexpected location (LocationListener.Changed, not LocationListener.Changing)

I'll resolve this in a v0.6.* release. The hard part will be adding anchors to the back / forward behavior.

[gnosygnu]

I added "Address bar should update with name of link" tonight.

I should be able to get "Back and forward does not work when clicking on Table of Contents links" for either v0.7.3 or v0.7.4

[gnosygnu]

I added this to v0.7.3. Note that v0.7.3 will also start logging TOC clicks in XowaPageHistory (which is similar to Firefox putting TOC clicks in its History)

I did run across one issue. Note that this revolves around "anchor clicks" which are defined as clicks on a link that is to somewhere on the same page: i.e.: of the form "#anchor". This is different than the standard page click which navigates to another page (i.e.: "/wiki/page"). Note that SWT does not tell me about an anchor click until after it is clicked (as opposed to a page click where I am told before)

Consider the following:

• User scrolls down 80 pixels
• User clicks on an anchor in the TOC
• Since SWT doesn't report an anchor click until afterwards, I have no way of knowing that the current vertical scroll position is 80
• User still gets navigated to the heading (which is say 500 pixels down)
• User then clicks "back". I don't know where to scroll to.

I could do either of the following:

• scroll to 0,0 (top of document). At first, this seemed generic enough. However, it didn't work well with pages where there is an opening paragraph, and the TOC is scrolled offscreen. It also affects screens with small viewports. For example, a 640x480 screen may have its TOC start at pos 480, and scrolling to 0,0 forces the user to scroll down again to reveal the TOC

• scrollTo id=toc. This seems to work well, but it assumes that all anchor clicks are from the toc. I've seen pages where the wikitext anchor-clicks to somewhere on the same page. (EX: "This was before he accomplished [[#some feat]]"). Scrolling back to the TOC would obviously be disorienting, but scrolling back to 0,0 is not any better.

I'm going to do the 2nd for now, b/c 95% of all anchor clicks will be coming from TOCs. For the 5% which are coming from elsewhere, I'll have to treat it as a known bug until SWT offers a "before clicked" event.