Either of these changes (ie dropping the setTabState call for batch restored
tabs, or ensuring the restoreTabs code correctly fills its array with dummy
entries) is sufficient here. I chose to do both because I think in both cases
the brokenness is not limited to this scenario or the issues at hand.
Specifically, the setTabState call was added in bug 1521346 to deal with
moved lazy tabs, but is now being invoked for session restore because of
the batchInsertingTabs optimization work. It doesn't actually need to be,
as far as I can tell, and the lacking _tPos in this case (because we don't
insert the tab into the tabstrip a few lines above) is what breaks things
inside _ensureNoNullsInTabDataList. Note that this _already_ was breaking
things in restoreTab(), which would assign into tabs[undefined] on the
window state object, so just dropping the call seemed better than wallpapering
the absence of _tPos.
The restoreTabs code, pre-patch, calls _ensureNoNullsInTabDataList but that
will never do anything, because right before calling it we change the array
length, so maxPos was always smaller than the size of the list. This meant
we still had empty slots in the array, which was also causing confusion down
the line.
I added the explicit exception for the broken _tPos in restoreTab so that we
notice any future issues with this more quickly. Doing so without any of the
other fixes broke the pre-existing browser_586068-apptabs.js test, so
hopefully that will catch any future changes that break the code's assumptions.
Differential Revision: https://phabricator.services.mozilla.com/D173070
Some of the tests that fail (or only succeed) with SHIP are currently marked for
Fission. This makes them fail once we turn on SHIP without Fission.
Differential Revision: https://phabricator.services.mozilla.com/D169824
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
There are 3 types of changes in this commit:
- from `loadURI(foo.spec)` to `loadURI(foo)`, as there's already a URI
- from `loadURI("string")` to `loadURI(Services.io.newURI("string"))` as the URL is hardcoded
- one or two where there is perhaps an intermediate variable but the patch
context should still make it trivial to ascertain the change is correct.
Depends on D168393
Differential Revision: https://phabricator.services.mozilla.com/D168394
This also updates layoutdebug.js, which in some ways pretends to be like a browser window but
is its own special snowflake. I kept the method naming conventions similar to the main
browser window.
Depends on D168394
Differential Revision: https://phabricator.services.mozilla.com/D168395
There are 3 types of changes in this commit:
- from `loadURI(foo.spec)` to `loadURI(foo)`, as there's already a URI
- from `loadURI("string")` to `loadURI(Services.io.newURI("string"))` as the URL is hardcoded
- one or two where there is perhaps an intermediate variable but the patch
context should still make it trivial to ascertain the change is correct.
Depends on D168393
Differential Revision: https://phabricator.services.mozilla.com/D168394
* If Firefox view tab is the last selected tab when a window is closed it
should not be saved; the first tab should be used instead. This patch updates a test,
updates the title that is saved and the selected index
Differential Revision: https://phabricator.services.mozilla.com/D166362
The previous part introduced a new mechanism to track the triggering remote
type for a specific load in a reliable way. This adds some basic checks based
on the triggering remote type to the nsContentSecurityManager, while also
providing the potential infrastructure to expand these checks in the future.
As these checks are performed before some other content security checks (to
ensure that they are performed before InitialSecurityCheckDone() is checked),
they may reject a load which would otherwise have been rejected by a later
check. For this reason, the diagnostic assertions added in this part are only
fired if the check appears as though it would otherwise have succeeded. This
check is not fully accurate, however, so may miss some cases.
This is important, as we have some tests, such as service worker navigation
tests, which will try to load file:/// URIs in content processes, and only fail
in the later content security checks.
For now, no checks are performed for non-document loads, though that may change
in the future.
Differential Revision: https://phabricator.services.mozilla.com/D161199
