Tapping the desired link does not redirect to specific page at .yongkang.org.tw when navigating in https-first mode (i.e. private browsing)
Categories
(Core :: DOM: Security, defect, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox99 | --- | affected |
People
(Reporter: rbucata, Unassigned)
References
(Blocks 1 open bug, )
Details
(Whiteboard: [domsecurity-backlog1])
Attachments
(1 file)
80.56 KB,
image/png
|
Details |
Environment:
Operating system: Android 11
Firefox version:Firefox Nightly 99.0a1 (2015862507 -🦎99.0a1-20220209095640🦎)
Preconditions:
PRIVATE BROWSING MODE Enabled
Clean profile
Steps to reproduce:
- Navigate to: http://www.yongkang.org.tw/.
- Tap on any link.
- Observe the result.
Expected Behavior:
A new page is loaded.
Actual Behavior:
The home page loads again.
Notes:
- Not reproducible in NORMAL BROWSING Mode.
- Works as expected using Chrome PRIVATE BROWSING Mode.
- Reproducible using Firefox Focus Release version.
- Screenshot attached.
Updated•3 years ago
|
Comment 1•3 years ago
|
||
Raul, I seem able to click on links in responsive design mode in private and strict mode on this page now. Has the site perhaps fixed this?
Reporter | ||
Comment 2•3 years ago
|
||
Tom, the issue is still reproducible for me when navigating in Private Mode.
Tested with:
Browser / Version: Firefox Nightly 101.0a1 (2015877963 -🦎101.0a1-20220430091922🦎)
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Comment 3•3 years ago
|
||
Ah, I see the problem in private mode as well, but it's unclear what is happening. I see no interesting notes in the console, even while trying to catch all exceptions. I also don't see any mention of service workers, caches, or indexeddb in their code, so this is a bit strange and will require a deeper diagnosis.
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 4•3 years ago
|
||
Raul, the links on this site seem to be working for me in private browsing now. Could you confirm?
Reporter | ||
Comment 5•3 years ago
|
||
Thomas, the issue is still reproducible for me:
https://media.giphy.com/media/ctoFPrUyEP8qSLmW3F/giphy.gif
Tested with:
Browser / Version: Firefox Release 101.2.0 (2015885315-🦎101.0.1-20220608170832 )/ Firefox Nightly 103.0a1 (2015886795-🦎103.0a1-20220615093700🦎)/ Chrome Mobile Version 102.0.5005.125
Operating System: Samsung A51 (Android 11) -1080 × 2400 pixels 20:9 aspect ratio (~405 ppi density)
Operating System: Google Pixel 3 (Android 12) -1080 x 2160 pixels, 18:9 ratio (~443 ppi density)
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•3 years ago
|
Comment 6•3 years ago
|
||
Interesting. When I click a link, in Private Browsing mode only it goes to that link but is immediately redirected by the server back to their main page. And even if I visit the URL of that link directly, say, http://www.yongkang.org.tw/index.php?option=module&lang=cht&task=pageinfo&id=792&index=3
the server still redirects.
Comparing the Curl requests being made it seems as though what's happening is that PBM is trying to load the HTTPS version of the link, but the site redirects back to the main page as it only supports HTTP.
Ah, if I change dom.security.https_first_pbm
in about:config to false, then this is working fine. I'll have to check if this is something we can work around, or if we'll just have to contact the site and see if they're willing to redirect HTTPS links to the same HTTP version, rather than just always redirecting back to their main page.
Updated•3 years ago
|
Comment 7•3 years ago
|
||
possible heuristic additions that might help in this case:
- If we've already failed to upgrade a site, set a temporary exception and don't try to upgrade other URLs on that origin in that tab. In this case since we failed to upgrade the main page we would not try to upgrade the link clicks that go to the same site.
- As a special exception, if an upgraded https: url redirects back to
http://site.example/
(i.e. insecure link to the bare domain with or without the trailing '/') then consider that as a signal the origin doesn't support https://. This kind of behavior is probably a re-write rule in a front-end appliance, as appears to be the case in bug 1759407
Option #1 would fit in nicely with the enhancements I suggest in bug 1776334, though a list of temporary exceptions could also be saved in the docshell or something similar if you didn't want to piggyback on the "https-only" permission mechanism.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 8•1 year ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Comment 9•5 months ago
|
||
Be aware, that URL is now an adult site.
It seems opening links on the site doesn't work in Firefox even though it works in Chrome. They open a new tab which immediately closes again.
Description
•