1934807 - Frameset: anchor with target in another frame does not scroll to target when pressed

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[oneofthedamons]

Attachment: Frameset with 2 sample frames

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:134.0) Gecko/20100101 Firefox/134.0

Steps to reproduce:

I appreciate framesets are well and truly deprecated, but this worked in Firefox 133 so it would appear something has broken it in 134.

A vendor of one of our legacy products supplies a large data dictionary as a frameset. We host it locally on a file share and access it in Firefox via file:///

While it's not sensitive it's not mine to publish so I have attached just the first 2 entries which nevertheless exhibits the faulty behaviour.

DDToc.html (left frame) includes anchor tags with their targets being named fragments in DDMain.htm (right frame), so that clicking <a target="main" href="DDMain.htm#FRAGMENT"> in DDToc.html should scroll to <a name="FRAGMENT"> in DDMain.htm

Note DataDictionary.htm is the container for the frameset. The sample only contains the first 2 entries, but this replicates the issue and so should be sufficient to illustrate the problem.

Actual results:

Clicking the anchor in DDToc.htm does not scroll to the named fragment in DDMain.htm

Expected results:

Until (and including) Firefox 133, clicking the anchor in DDToc.htm scrolled to the name fragment in DDMain.htm

Comment 1

[oneofthedamons]

Attachment: Frameset.zip

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Navigation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 3

[Adam Vandolder [:avandolder]]

I'm unable to reproduce this failure on Fedora Linux 41 - the scrolling appears to occur in 133, the latest 134 beta, and the latest 135 nightly.

oneofthedamons, would it be possible for you to capture a profile of the failure and attach it here?

Comment 4

[oneofthedamons]

Well this is interesting. I cannot replicate the issue on MacOS (134-beta) but I can running 134-beta on a newly imaged Windows 10 machine. No issue on 133-release. As the Windows 10 profile was brand new, not signed-in with a Mozilla account, I can't see how it's a profile issue.

Comment 5

[oneofthedamons]

Is someone able to test on Windows to see if there's something weird with our environment (which I must admit I'd suspect, although I can't think of what it might be) or if this is a Windows-specific bug?

Comment 6

[oneofthedamons]

Now that I've been shown how to use mozregression on another bug, I can report mozregression indicates the change was in Bug 1879820 with the pushlog URL: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=43332b0febc24bfdab47366e72b376cf7c68e330&tochange=639d61a9a326ce05c6bd095c628841a03b09c7dc

Comment 7

[Jan Jaeschke [:jjaschke]]

Thank you for looking into it. Edgar, I'm forwarding this to you. :)

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1879820

Comment 12

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&revision=35d6ff6cd444dcac744cfda73f3ee7e5aad55f72

Comment 13

[Edgar Chen [:edgar]]

https://treeherder.mozilla.org/jobs?repo=try&revision=a109e2efe303ffa4d09848fa06b3c03fd590f152

Comment 14

[Edgar Chen [:edgar]]

Attachment: Bug 1934807 - Consider file: URIs as the same domain for the purpose of frame navigation; r?#dom-core

We set up am AutoJSAPI in OnLinkClickSync for trusted clicks as well after
D201373. This causes link clicks to be blocked by nsDocShell::CheckLoadingPermissions()
if the target frame is cross-origin and resides in the same process. Under fission,
this isn't a problem since the load usually occurs in a different process, except
for file:// URLs.

Comment 17

[Pascal Chevrel:pascalc]

Resetting releases in flight to affected and tracking as we already have 2 duplicates indicating web breakage since we shipped 134.

Comment 19

[BugBot [:suhaib / :marco/ :calixte]]

The bug is marked as tracked for firefox134 (release) and tracked for firefox135 (beta). However, the bug still has low severity.

:hsinyi, could you please increase the severity for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 20

[Edgar Chen [:edgar]]

Attachment: Bug 1934807 - Consider file: URIs as the same domain for the purpose of frame navigation; r?#dom-core

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a278f9295b80
Consider file: URIs as the same domain for the purpose of frame navigation; r=smaug

Comment 22

[amarc]

https://hg.mozilla.org/mozilla-central/rev/a278f9295b80

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:edgar, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Comment 25

[Pascal Chevrel:pascalc]

Edgar, could you request uplift for the beta and release branches once this has been verified by QA on NIghtly? This is too late for the dot release that we are building today, but I'd love to know our options for the planned dot release next week, thanks!

Comment 26

[Edgar Chen [:edgar]]

Comment on attachment 9444272 [details]
Bug 1934807 - Consider file: URIs as the same domain for the purpose of frame navigation; r?#dom-core

Beta/Release Uplift Approval Request

• User impact if declined/Reason for urgency: Clicking a targeted link to navigate other frame doesn't work in local files
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1. Download test pages in Bug 1934807 comment# 1

2. Load DataDictionary.htm
3. Click link in left frame

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Should be low, we only do special handling for file:// URI explicitly.
• String changes made/needed: None
• Is Android affected?: Yes

Comment 27

[Edgar Chen [:edgar]]

(I also verified this on latest Nightly)

Comment 28

[Peter Magyari (Desktop QA)]

Verified fixed using Nightly 136.0a1 (20250114093520) on MacOS 14 and Windows 11.

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9444272 [details]
Bug 1934807 - Consider file: URIs as the same domain for the purpose of frame navigation; r?#dom-core

Approved for 135.0b5.

Comment 32

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/853abed2683c

Comment 33

[Peter Magyari (Desktop QA)]

Verified fixed on 135.0b5 (20250115025558)

Comment 35

[Pascal Chevrel:pascalc]

Comment on attachment 9444272 [details]
Bug 1934807 - Consider file: URIs as the same domain for the purpose of frame navigation; r?#dom-core

Approved for our planned 134 dot release, thanks.

Comment 36

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-release/rev/80501a5cd679

Comment 38

[Peter Magyari (Desktop QA)]

Verified fixed on Firefox 134.0.2 (20250120093826) build from Comment 36.

Comment 39

[Edgar Chen [:edgar]]

I filed bug 1943904 to investigate whether we can write a test to prevent further regressions.