MantisBT - NetSurf
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002740NetSurf[All Projects] Generalpublic2020-03-15 14:542020-05-26 21:32
ReporterHarriet Bazley 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusassignedResolutionopen 
PlatformARMiniXOSRISC OSOS Version5.27
Product Version 
Target VersionFixed in Version 
Fixed in CI build #
Reported in CI build #5041
URL of problem pagehttps://en.wikipedia.org/wiki/Paper_size#Soviet_variants
Summary0002740: Contents links in WIkipedia don't work
DescriptionClicking 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 ReproduceLoad 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 InformationSame 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....
TagsNo tags attached.
Relationships
Attached Filesjpg screen.jpg (101,509) 2020-03-15 14:54
https://bugs.netsurf-browser.org/mantis/file_download.php?file_id=647&type=bug
jpg

zip Demo.zip (375,490) 2020-05-26 20:47
https://bugs.netsurf-browser.org/mantis/file_download.php?file_id=674&type=bug

Notes
(0002186)
Harriet Bazley   
2020-05-05 23:39   
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).
(0002204)
Dave Higton   
2020-05-26 20: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?
(0002205)
Dave Higton   
2020-05-26 21:32   
(FYI, I've reported point 2 above as bug 2769.)

Issue History
Date ModifiedUsernameFieldChange
2020-03-15 14:54Harriet BazleyNew Issue
2020-03-15 14:54Harriet BazleyFile Added: screen.jpg
2020-05-05 23:39Harriet BazleyNote Added: 0002186
2020-05-21 21:25Michael DrakeAssigned To => Michael Drake
2020-05-21 21:25Michael DrakeStatusnew => acknowledged
2020-05-21 21:25Michael DrakeDescription Updatedbug_revision_view_page.php?rev_id=2175#r2175
2020-05-21 21:25Michael DrakeSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=2177#r2177
2020-05-21 21:25Michael DrakeAdditional Information Updatedbug_revision_view_page.php?rev_id=2179#r2179
2020-05-21 21:28Michael DrakeAssigned ToMichael Drake =>
2020-05-21 21:28Michael DrakeStatusacknowledged => assigned
2020-05-26 20:47Dave HigtonFile Added: Demo.zip
2020-05-26 20:47Dave HigtonNote Added: 0002204
2020-05-26 20:47Dave HigtonNote Edited: 0002204bug_revision_view_page.php?bugnote_id=2204#r2187
2020-05-26 21:32Dave HigtonNote Added: 0002205