Bug 1696815 Comment 0 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

bug 1498432 introduced a unit test that basically opens a discarded/lazy tab browser, and then navigates it to a new URL. As part of the tabbrowser implementation, [restoration of the tab starts first](https://searchfox.org/mozilla-central/rev/52a3b19a3de21546f6ab9c10d37d6047107ed874/browser/base/content/tabbrowser.js#2189-2201) before the actual navigation. The existing logic expects the `pending` to be removed eventually, but it is still there.
I have previously explained the relation between the "pending" attribute and the non-updating of tabs at https://bugzilla.mozilla.org/show_bug.cgi?id=1511756#c7 . It is possible for the two bugs to share the same causes, but I did not bother investigating further prior to filing this bug.

To reproduce this bug, start Firefox with Fission enabled ( `MOZ_FORCE_ENABLE_FISSION=1` ) and open then navigate the tab by running the following code in the devtools console of an extension page (use `about:debugging` to inspect an extension; any extension will do):
```
t = await browser.tabs.create({ url: "http://example.com/1st", discarded:true});
await browser.tabs.update(t.id, { url: "http://example.com/2nd" });
```

Expected: The title should be "Example Domain"
Actual: The title is `example.com/2nd`.
`gBrowser.tabs[2].hasAttribute("pending")` is unexpectedly true. (if the new tab is the 3rd tab).

To test as a developer:

1. Remove the `skip-if = fission` from `browser_ext_tabs_discard_reversed.js` in `browser/components/extensions/test/browser/browser.ini` (added in bug 1498432 ).
```
./mach test browser/components/extensions/test/browser/browser.ini --enable-fission
```

If you want to inspect the state of the browser when the failure is happening, comment out the `resolve()` at https://hg.mozilla.org/integration/autoland/rev/9ce142e600af#l3.61 (expected: title changed, actual/wrong: title looks like a URL).
bug 1498432 introduced a unit test that basically opens a discarded/lazy tab browser, and then navigates it to a new URL. As part of the tabbrowser implementation, [restoration of the tab starts first](https://searchfox.org/mozilla-central/rev/52a3b19a3de21546f6ab9c10d37d6047107ed874/browser/base/content/tabbrowser.js#2189-2201) before the actual navigation. The existing logic expects the `pending` to be removed eventually, but it is still there when Fission is turned on.
I have previously explained the relation between the "pending" attribute and the non-updating of tabs at https://bugzilla.mozilla.org/show_bug.cgi?id=1511756#c7 . It is possible for the two bugs to share the same causes, but I did not bother investigating further prior to filing this bug.

To reproduce this bug, start Firefox with Fission enabled ( `MOZ_FORCE_ENABLE_FISSION=1` ) and open then navigate the tab by running the following code in the devtools console of an extension page (use `about:debugging` to inspect an extension; any extension will do):
```
t = await browser.tabs.create({ url: "http://example.com/1st", discarded:true});
await browser.tabs.update(t.id, { url: "http://example.com/2nd" });
```

Expected: The title should be "Example Domain"
Actual: The title is `example.com/2nd`.
`gBrowser.tabs[2].hasAttribute("pending")` is unexpectedly true. (if the new tab is the 3rd tab).

To test as a developer:

1. Remove the `skip-if = fission` from `browser_ext_tabs_discard_reversed.js` in `browser/components/extensions/test/browser/browser.ini` (added in bug 1498432 ).
```
./mach test browser/components/extensions/test/browser/browser_ext_tabs_discard_reversed.js --enable-fission
```

If you want to inspect the state of the browser when the failure is happening, comment out the `resolve()` at https://hg.mozilla.org/integration/autoland/rev/9ce142e600af#l3.61 (expected: title changed, actual/wrong: title looks like a URL).

Back to Bug 1696815 Comment 0