Open Bug 1754982 Opened 3 years ago Updated 5 months ago

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)

Firefox 99
Other
Android
defect

Tracking

()

REOPENED
Tracking Status
firefox99 --- affected

People

(Reporter: rbucata, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(1 file)

Attached image Screenshot_36.png

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:

  1. Navigate to: http://www.yongkang.org.tw/.
  2. Tap on any link.
  3. 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.
Blocks: tp-breakage
Severity: -- → S3

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?

Flags: needinfo?(raul.bucata)

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)

Flags: needinfo?(raul.bucata)

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.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
No longer blocks: tp-breakage

Raul, the links on this site seem to be working for me in private browsing now. Could you confirm?

Flags: needinfo?(raul.bucata)

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)

Flags: needinfo?(raul.bucata)
Summary: Tapping the desired link does not redirect to specific page when navigating in PRIVATE BROWSING Mode → Tapping the desired link does not redirect to specific page at .yongkang.org.tw when navigating in PRIVATE BROWSING Modet
Summary: Tapping the desired link does not redirect to specific page at .yongkang.org.tw when navigating in PRIVATE BROWSING Modet → Tapping the desired link does not redirect to specific page at .yongkang.org.tw when navigating in PRIVATE BROWSING Mode

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.

Blocks: tp-breakage
No longer blocks: tp-pbm-missing-api-breakage
Blocks: https-first-mode
No longer blocks: tp-breakage
Component: Privacy: Anti-Tracking → DOM: Security

possible heuristic additions that might help in this case:

  1. 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.
  2. 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.

See Also: → 1776334
Summary: Tapping the desired link does not redirect to specific page at .yongkang.org.tw when navigating in PRIVATE BROWSING Mode → Tapping the desired link does not redirect to specific page at .yongkang.org.tw when navigating in https-first mode (i.e. private browsing)
Assignee: nobody → lyavor
Whiteboard: [domsecurity-backlog1]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: t.yavor → nobody

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.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: