2024-11-24 14:59 UTC
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002740NetSurf[All Projects] Generalpublic2020-03-15 14:542020-05-26 20:32
ReporterHarriet Bazley 
Assigned To 
SeverityminorReproducibilityalways 
StatusassignedResolutionopen 
PlatformARMiniXOSRISC OSOS Version5.27
Product Version 
Target VersionFixed in Version 
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.
Fixed in CI build #
Reported in CI build #5041
URL of problem pagehttps://en.wikipedia.org/wiki/Paper_size#Soviet_variants
Attached Files

-Relationships
+Relationships

-Notes
Harriet Bazley

~0002186

Harriet Bazley (reporter)

2020-05-05 22: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).
Dave Higton

~0002204

Dave Higton (developer)

2020-05-26 19:47

Last edited: 2020-05-26 19:47

View 2 revisions

 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

~0002205

Dave Higton (developer)

2020-05-26 20:32

 (FYI, I've reported point 2 above as bug 2769.)
+Notes

-Issue History
Date Modified Username Field Change
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
+Issue History