|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002740||NetSurf||[All Projects] General||public||2020-03-15 14:54||2020-05-26 20:32|
|Platform||ARMiniX||OS||RISC OS||OS Version||5.27|
|Target Version||Fixed in Version|
|Summary||0002740: Contents links in WIkipedia don't work|
|Description||Clicking on any link in a Wikipedia Contents section fails to work. There is no visible response; the page doesn't reload, and it doesn't scroll to the relevant heading.|
If you Adjust-click to force the link to open in a new window, the window opens with a horizontally restricted work area and a blank section to the right (see attached image), with the page scrolled sideways hiding the area to the left of the main frame e.g. https://en.wikipedia.org/wiki/Paper_size#Soviet_variants
N.B. If you edit the URL in such a page to remove the anchor and reload, the content then expands back to fill the full width of the page.
|Steps To Reproduce||Load a Wikipedia page, e.g.https://en.wikipedia.org/wiki/Paper_size|
Click on a link on the contents box, e.g. "Soviet variants"
|Additional Information||Same behaviour seen in Netsurf v4358.|
Interior links within a Web page appear to function as normal on other websites.
Possibly an issue with frame handling? All Wikipedia pages are now showing up with a frame scrollbar down the right-hand side, overlaying the edge of the content....
|Tags||No tags attached.|
|Fixed in CI build #|
|Reported in CI build #||5041|
|URL of problem page||https://en.wikipedia.org/wiki/Paper_size#Soviet_variants|
Harriet Bazley (reporter)
|Searches aren't working properly on Wikipedia pages, either. The found string gets highlighted, but the window doesn't scroll to bring it within view, which makes the search function fairly useless on long pages (which is where it's mainly necessary).|
Dave Higton (developer)
Last edited: 2020-05-26 19:47
I've been experimenting. The problem is related to the handling of the "overflow-y" CSS property. The page sets it to "scroll". NS adds its own set of scroll bars, duplicating what RISC OS provides. This seems pointless to me.
The file "Demo.zip" is from a full save of the page, with two edits:
1) In the CSS file 0x52826cc0, I've changed the overflow-y value to "visible".
2) NS had converted all the navigation links in the HTML file "index" to external ones, so I've edited all of them back to internal. Without that change, any click would of course cause NS to reload the page from Wikipedia.
Now there are no extra unwanted scroll bars, and all the internal links work correctly.
So, my question is: should overflow-y always be treated as "visible"? Is there any reason not to?
Dave Higton (developer)
|(FYI, I've reported point 2 above as bug 2769.)|
|2020-03-15 14:54||Harriet Bazley||New Issue|
|2020-03-15 14:54||Harriet Bazley||File Added: screen.jpg|
|2020-05-05 22:39||Harriet Bazley||Note Added: 0002186|
|2020-05-21 20:25||Michael Drake||Assigned To||=> Michael Drake|
|2020-05-21 20:25||Michael Drake||Status||new => acknowledged|
|2020-05-21 20:25||Michael Drake||Description Updated||View Revisions|
|2020-05-21 20:25||Michael Drake||Steps to Reproduce Updated||View Revisions|
|2020-05-21 20:25||Michael Drake||Additional Information Updated||View Revisions|
|2020-05-21 20:28||Michael Drake||Assigned To||Michael Drake =>|
|2020-05-21 20:28||Michael Drake||Status||acknowledged => assigned|
|2020-05-26 19:47||Dave Higton||File Added: Demo.zip|
|2020-05-26 19:47||Dave Higton||Note Added: 0002204|
|2020-05-26 19:47||Dave Higton||Note Edited: 0002204||View Revisions|
|2020-05-26 20:32||Dave Higton||Note Added: 0002205|