[SHIP] A misleading "Go back" button is displayed after refreshing warning pages, although there are no other tabs to return to
Categories
(GeckoView :: General, defect)
Tracking
(firefox134 disabled, firefox135 disabled, firefox136 affected)
People
(Reporter: dpop, Assigned: olivia)
References
(Blocks 1 open bug)
Details
(Whiteboard: [group1][fxdroid])
Attachments
(3 files)
Preconditions
- Make sure you are enrolled in the https://experimenter.services.mozilla.com/nimbus/android-fissionship-nightly-experiment-for-qa/summary experiment, in the # fission-on branch.
- Go to about:config and make sure the following prefs are set accordingly: fission.autostart=true and fission.disableSessionHistoryInParent=false
Steps to reproduce
- Open https://expired.badssl.com/ in a new tab.
- Tap on the "Advanced..." button.
- Refresh the page or tap on the "Try again" button.
- Tap on the "Advanced..." button again.
- Observe the options available.
Expected behavior
If the https://expired.badssl.com/ URL is not accessed from an existing opened tab in Step 1, only the "Accept the Risk and Continue" option should be available.
Actual behavior
Two button options:
- Go Back (Recommended) - the button has no functionality
- Accept the Risk and Continue;
Device information
- Firefox version: Nightly 136.0a1 from 01/29
- Android device model/Android OS version: Google Pixel 8 Pro (Android 14) and any device
Additional information
The issue is reproducible with other error pages as well: http://itisatrap.org/firefox/unwanted.html, http://testsafebrowsing.appspot.com/s/unwanted.html, https://www.itisatrap.org/firefox/its-a-trap.html .
Not reproducible with Fission off.
Reporter | ||
Comment 1•10 days ago
|
||
Reporter | ||
Comment 2•10 days ago
|
||
Updated•4 days ago
|
Updated•4 days ago
|
Assignee | ||
Updated•4 days ago
|
Assignee | ||
Comment 3•3 days ago
•
|
||
Fission or SHIP (more likely) appears to have caused a change in window.history.length
implementation here. Button is badCertGoBack for more references. I'll write a GeckoView test to fully demonstrate the bug and then I'll start unwinding the implementation.
Assignee | ||
Comment 4•2 days ago
•
|
||
Was able to confirm SHIP causes the regression.
This seems specific to Fenix: window.history.length = 1
with SHIP disabled and window.history.length = 2
with SHIP enabled. It appears SHIP enabled starts out with 2
initially.
On GV, visiting the same page: window.history.length = 1
on both cases. Can't truly reproduce on GV because a custom error page is involved, but it is suspicious that the initial counts on Fenix aren't as expected.
Assignee | ||
Updated•2 days ago
|
Assignee | ||
Comment 5•1 day ago
|
||
Adding some more information from the investigation:
Both SHIP / non-Ship content process has this error:
Content-Security-Policy: The page’s settings blocked an inline script (script-src-elem) from being executed because it violates the following directive: “default-src resource:” resource://android/assets/low_and_medium_risk_error_pages.html?&title=Secure+Connection+Failed&butto:79:34
The page loaded is low_and_medium_risk_error_pages.html
, I think this script is being blocked is what it is possibly referring to. This was added for https://github.com/mozilla-mobile/fenix/issues/14552, which is also related to being able to go back when there is no history to go back to. So, a possible lead there as well.
Assignee | ||
Comment 6•1 day ago
•
|
||
edit: SHIP had switched back off during a code reload and this didn't solve the issue. Fixing the CSP appears to fix the issue - I'll take it this route since the issue couldn't be simply reproduced in GVE. I'm not entirely sure why it created a second history entry when SHIP was enabled. From debugging, the best I could tell was it happened after initial onload.
Description
•