1727679 - 78.13.0esr (64-bit) - not able to open my anchor tag link in same window

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect, P5)

Description

[Umang]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

Steps to reproduce:

I have Jira cloud app.

Jira is provided iframe container to load our app. we are generating anchor link with hash tag (#) without target element.

My link is not clickable.

Actual results:

My link is not working inside iframe if I didn't mention target element.

Comment 1

[Negritas Sergiu, Desktop QA]

Hello I have tried to reproduce the issue using Firefox 92.0b8 and 93.0a1(2021-08-26) unfortunately I wasn't able to reproduce it. Could you please answer the following questions in order to further investigate this issue?

1. Does this issue happen with a new profile? Here is a link on how to create one: https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles
2. Does this issue happen in the latest nightly? Here is a link from where you can download it: https://www.mozilla.org/en-US/firefox/channel/desktop/
3. Do you have any addons installed if so can you list them?

Comment 2

[Andre Klapper]

Please provide a self-contained testcase which allows others to reproduce.

Comment 3

[Umang]

Hey Andre,

We are able to reproduce this issue in specific version of Firefox 78.13.0 which is ESR release.
https://www.mozilla.org/en-US/firefox/78.13.0/releasenotes/

One of our customer is using older browser for specific reason. However its working perfectly fine in all Firefox 80+ versions.

Thanks,
Umang

Comment 4

[Andre Klapper]

Okay. Please see my previous comment again.

Comment 5

[Umang]

if you can provide your email I can add you in my test instance. where you can try our app in firefox 78 version.

Video link for step to reproduce: https://photos.app.goo.gl/dTP4MtDiAuCJgzkr8

Thanks,
Umang

Comment 6

[:Gijs (he/him)]

From the video it's impossible to tell what the full URL is of the page on which you click the "DEMO-TC-14" link, but the link target includes a hash # and the non-ref part of the URL looks like it's likely to be the same. So you're just changing the hash part of the URL, and given it's in an iframe it's not possible to see if this is changing or not; I expect that there is some difference in whether hashchange events are firing and/or how your app is coping with those events - but we'd really need to have access to a minimal testcase to work out what is going on. In order for Firefox to change something here you'd need to show more clearly exactly what is going wrong.

Comment 7

[Umang]

If you can share your detail. I will add u in my test env so you can access and reproduce issue from your end.

Comment 8

[:Gijs (he/him)]

(In reply to Umang from comment #7)

If you can share your detail. I will add u in my test env so you can access and reproduce issue from your end.

I'm not willing to do that. It would still require reverse engineering whatever JIRA and your code is/are supposed to be doing in response to the hash change. We're not a "debug my problems on demand for free" service, and I just don't have time to wade through and narrow down the issue. As it is right now, 78esr is almost end-of-life (91 esr is already being released), you've said you can't reproduce the issue on Firefox 80 or later, and we've not been inundated with similar reports of "links not working", so without a narrowed down testcase with more details that clearly points out what the browser is doing wrong, it seems very unlikely that (a) this is a Firefox bug; or if it is that (b) it is related to links and (c) that we can actually fix it safely on the ESR branch.

Comment 9

[Umang]

I understand. You can mark this issue as of now. will update our user to use latest 91 version of firefrox, As our app is working perfectly fine with that.

Comment 10

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

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

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Perhaps, we shouldn't land patches for changing behavior into 78esr anymore since it may break web apps which depend on the bug. However, if it's caused by some incompatible things, and 80+ just hides it unexpectedly, we need to fix the root cause. Umang, if you provide a minimized testcase to reproduce it, we'd investigate it. Otherwise, we can do nothing.

FYI: You can try to find the fix point with mozregression:
https://mozilla.github.io/mozregression/

If let us know the behavior change range, it's really helpful for us.

Will you do one of or both of them? Otherwise, this should be marked as WORKSFOME.