back history will be cleared on reloading an extension page
Categories
(WebExtensions :: Request Handling, defect, P2)
Tracking
(Not tracked)
People
(Reporter: kernp25, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
Load the attached add-on.
Open example.com and wait for the extension page to load.
Reload the page .
Actual results:
The back history of the tab will be lost.
Expected results:
The back history of the tab should not be cleared on reloading the page.
Use this link for testing:
https://example.com/
|
||
Comment 3•6 years ago
|
||
Using redirectUrl in webRequest is like a HTTP 302 redirect, i.e. it's a temporary redirect that replaces the requested URL. Therefore it won't end up being used in the history entry.
If I load example.org before navigating to https://example.com using your extension, then I do see that the history is preserved.
I tested this with Firefox 67.0.4 and Firefox 69.0a1 buildID 20190624213657.
In the future, if you report bugs in Firefox, could you also mention the exact version that you're using in your test? You can find this information at about:support .
|
|
||
Comment 7•6 years ago
|
||
Ah, I missed the reload step. This is a valid bug.
If I directly navigate to the web-accessible moz-extension:-URL, then the history is preserved even upon reload.
|
||
Updated•6 years ago
|
|
|
||
Comment 8•5 years ago
|
||
After investigating the issue, I found that there are two things:
- In the broken case, after the webRequest redirect the extension is in the wrong process. This is bug 1573456.
- When the user reloads the tab, a process switch is forced, resulting in loss of history.
This reported issue appears to have been fixed in 72, then broken again in 73 and then fixed in 73/74. I didn't check the details of the breakages in between, but the least we can do is to add a unit test in bug 1573456 to prevent the regression from occurring again.
(You can stop reading now, unless you're interested in how I reached the above conclusion)
When I ran mozregression in an attempt to find the cause of the fix, I got confused.
I consistently get the same regression ranges:
- Beta: broken in 73, fixed in 74 - https://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=14ac73797dd828cc30a99df36befbec79069bde4&tochange=ace4081e82005a35eca94a9c74286d5d4b519741
- Nightly: broken in 71, fixed in 72 - https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=07a4c42fecf6434c712f690a77e30ef44dbe0944&tochange=440eac58d324fd982a89a21c25a6c9d2a9c8ccf6
- Release: broken in 72, 73
Because of the inconclusive regression range, I looked into it a bit further.
While trying to reproduce, I tried to automate the test, and found that using browser.tabs.reload does not reproduce the issue, whereas using a keyboard shortcut or pressing the browser's reload button does reproduce the issue. In the first case, browser.reloadWithFlags is used directly. In the latter case, the final handler is BrowserReloadWithFlags (via BrowserReloadOrDuplicate), which is sensitive to the value of browser.processType.
Another observation is that the issue also reproduces if the current URL is a moz-extension:-URL. In that case the tab browser's remoteType is web, which reminds me of bug 1573456 .
With the ability to reproduce the bug (Firefox 73 Beta) and not (Firefox 74 Nightly), I patched omni.ja by adding logging to getRemoteTypeForPrincipal, and found that in the good case, onMayChangeProcess is called, but not in the bad case. This specific behavior changed in bug 1584031 (https://hg.mozilla.org/mozilla-central/rev/7a1d40167829) and looks like a plausible cause of the fixed behavior in Nightly 72.
I'm not interested in completely figuring out why it broke and got fixed in 73, but since we have a plausible fix and the latest beta&nightly versions work, we can consider writing a unit test to avoid future regressions (todo for bug 1573456).
Description
•