This'll allow customising context menu/session store/... behaviour in Gecko depending on the tab type, since in the future we might not only have special behaviour for custom tabs, but for web app tabs etc. as well.
MozReview-Commit-ID: LS6oGfO4KpR
--HG--
extra : rebase_source : 677a013a05cc683cae82c84864509d8f4799b474
Every way I've tried to move a browser in the deck results in the browser being
reset (it loses its docShell and contentDocument). So now we treat
deck.children as a set of browsers instead of a list, and make BrowserApp._tabs
the sole keeper of the user visible tabs list order. That means
deck.selectedIndex should no longer be used to get the user visible index of the
currently selected tab (deck.selectedPanel is still valid), and that all
additions to deck can be appends.
Note if this gets reverted at some later date: there's currently a bug, which
this change renders moot, where we reinsert a close-undo tab correctly in the
_tabs list, but incorrectly append it to the deck instead of inserting it.
MozReview-Commit-ID: Id7FR1p1nfN
--HG--
extra : rebase_source : 1506f513e653c67d066601fb9038bee098be9479
The session store keeps a serialised copy of a tab's session history around so that the gathering of the data (which can be somewhat expensive) can be decoupled from writing it to disk.
When the user clears Firefox's history, we therefore need to discard this data as well (except for the currently open entry), so it doesn't stick around until the next time some navigation/history change occurs in that tab. Otherwise, if Firefox or just the tab is closed before the purged state has been re-collected by the session store, the supposedly purged session history will resurface when the tab is restored again.
Bug 1337940 means that we'll now catch the history notifications caused by the session history being purged, however
- we still need to handle zombified tabs separately, since as far as the rest of Gecko is concerned, those simply consist of a plain "about:blank" browser with the true state being stashed away in the session store data, so the purging of the live session history data won't have any real effect
- the history purging on the tab happens after the session store receives the "browser:purge-session-history" notification, meaning that these changes received through the regular history notifications won't get written to disk immediately
Therefore we now explicitly purge the session history data of all tabs in our notification handler, so this state can then immediately be saved to disk.
MozReview-Commit-ID: KkR0Tif9BBk
--HG--
extra : rebase_source : 5744c88e2871cd873e2484e9688deb53bf8d44f2
Fennec's session store code was forked from Desktop a few years ago. Since then, the Desktop session store code has been refactored and modularised, which allows us to pull in again the bits the are compatible with our session store architecture and don't require any mobile-specific handling.
The handling of session history is such a case - with the exception of the "wyciwyg" filtering, any differences between SessionHistory.jsm and our equivalent in sessionstore.js seems to stem from Desktop bugfixes that were never ported over to our copy of the code.
Switching Fennec's session store over to use SessionHistory.jsm will prevent those sort of errors from occurring again in the future and hopefully simplify the maintenance of the session history code going forward.
MozReview-Commit-ID: Hm0TWTwtPsI
--HG--
extra : rebase_source : 5935c7baeefbd2c75754fe609b684aaf40ee85e9
So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available.
However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state.
To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab.
Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state.
MozReview-Commit-ID: LgHer940QwT
--HG--
extra : rebase_source : f5ec320bd21dac91bf1baa162aaabae3ced911e3
Currently, Recently Closed is displaying the last available history entry for each closed tab instead of the history entry that was actually being shown at the time the tab was closed.
The Java session parser that is responsible for displaying the last session's tabs when not automatically restoring is already doing the correct thing and therefore doesn't need changing.
MozReview-Commit-ID: DGaD52SzdpP
--HG--
extra : rebase_source : 0f11b32d3d8f1061681706272b62dfb090e8e598
So far we've simply used DOMTitleChanged as a proxy for navigation, since it's the earliest opportunity at which we have all necessary data for a new history entry (session history itself as well as tab URL and *title*) available.
However it turns out that this is not 100 % reliable, since some pages might e.g. implement their navigation in JS using the history API, which won't necessarily trigger any DOMTitleChanged events. In those case we'd fail to update the tab's session history in the session store unless the user eventually navigated to someplace else that actually triggers a title change event again - if the browser was closed before that, we'd fail to properly restore the user's state.
To fix this, we take a similar approach as the desktop session store and collect a tab's history data again when receiving any history change notification for that tab.
Because the OnHistory... notifications are mostly cancellable, the session history hasn't been actually updated yet at the point the history listener is being called. We therefore can't synchronously call onTabLoad() from within our history change notification handler and have to schedule an async timeout instead so as to give the session history a chance to complete updating its state.
MozReview-Commit-ID: LgHer940QwT
--HG--
extra : rebase_source : a9634be57f3f43e30f42431e8a28846d958534ee
This should be more foolproof than having to remember to use the dedicated setParentId() function when writing to that variable from outside of the tab constructor.
MozReview-Commit-ID: 1KlXf60VsoF
--HG--
extra : rebase_source : 3ae5234a0113b6077a91e873c7a5e5919b162af3
During a cold startup, depending how this exactly plays out we might receive an application-foreground notification before the browser window is ready. Since the code to restore the selected tab if it has been left zombified while in background is only relevant if Gecko was already running and backgrounded, we can simply add a null check for the window before accessing it.
MozReview-Commit-ID: Ahp5NAODKRF
--HG--
extra : rebase_source : bede266e13f48fbc2f7efd40bb9277be6d2bd3bf
onTabLoad() means we've potentially navigated to a new page, in which case any auxiliary tab data we keep around for the currently loaded page only (form input data, scroll position) would be invalidated and shouldn't be preserved.
Since onTabLoad() can however also be triggered if e.g. just the tab title changed (an additional DOMTitleChanged event), we shouldn't throw away the old data without replacing it with the current state, though. We already do this for the form input data - we need to do it for the scroll position as well.
MozReview-Commit-ID: HG7g6L7htDG
--HG--
extra : rebase_source : 1f7aab26002ee71237dd0a48b872298b39ca7f13
Since bug 1228593, the mobile session store
- once again flushes its data when we are quitting, to make sure the latest state (including any potential cleaning of history/tabs) is flushed to disk
- ignores windows/tabs closing as a byproduct of shutdown
The latter point is dependent on a new shutdown notification introduced in that bug. Because we forgot to add that notification to the restart code used for add-on updates, in that case the session store currently doesn't enter shutdown mode and therefore records the window being closed during shutdown before flushing its data to disk, which means that all open tabs are lost.
MozReview-Commit-ID: LgtdQoYwacM
--HG--
extra : rebase_source : 1bf6c544d9e25961a0e64236678ca5938e8a69fe
Actors outside of the session store shouldn't have to poke around within the session store's data structure and end up reimplementing parts of the session store code (and cause data loss if the implementation is incomplete) in order to restore delay loaded zombie tabs. Therefore, we simply expose a method for this via BrowserApp's tab object.
To simplify handling and make the method a little more fool-proof for external callers, the check whether the tab is actually zombified is moved into the restoreZombieTab() function.
Later on, we can also hook up this method to the appropriate web extension API (see bug 1322485).
MozReview-Commit-ID: 85lnbCpMcP3
--HG--
extra : rebase_source : a6f1cfa11debcb18471b49804776521c60655fce
We've been parsing the session store file and doing the initial tab creation on the Java side for a long time now, so the code to open completely new tabs on the session store side instead of using tab stubs is no longer necessary.
Besides, because of bug 1301160 the on-disk session file is now containing tab IDs as well, so this distinction between tabs read directly from the raw session file and those contained in a session string passed over from the Java UI is no longer available.
MozReview-Commit-ID: Hmq0TwClqMQ
--HG--
extra : rebase_source : 1f9ab6da18a7fd0f40a1cb0784082abb2384404f
This is relevant when a new tab is opened (e.g. through an intent from an external app) just as the user has pressed the Quit button (see bug 1266594), in which case the TabOpen event might reach the session store after Gecko shutdown has already started. If we're still in the preliminary phase and the browser window hasn't yet been closed, we can persist this new tab by collecting the session store data from the browser window once more.
Additionally, we now reset the time of the last backup when clearing the session store data, so the backup file is recreated as soon as possible after a history/tabs sanitisation, especially for users who are cleaning private data on exiting Firefox.
MozReview-Commit-ID: 9BmqrSIUJ42
--HG--
extra : rebase_source : be3c413db16523aac69d8283f36057713c1e9367
When restoring recently closed tabs during a browsing session, we can just pass the stored parentId as a parameter to addTab and be done with it.
During startup however, we first need to update the parent tab IDs before being able to use it.
At the moment, new tabs are always opened at the end of the tab list and cannot be resorted by the user, so child tabs always appear *after* their parent tabs in the tab list. However because we don't want to rely on this behaviour, we still need to collect a complete mapping between old and new tab IDs first before being able to update the stored parent tab IDs.
Therefore we cannot use the usual method of passing in the parentId during tab creation and have to set it after the fact for this case.
MozReview-Commit-ID: JT5YSkuOSZw
--HG--
extra : rebase_source : 5487f05ed5fd99e12e4f33170688243b36da55e4
Having the previous tab ID in the session store data is required in order to be able to create a mapping between old and new IDs on starting up.
Likewise, the parent ID now needs to be tracked on the Gecko side as well, so it can be saved by the session store and later used when restoring a tab/session.
MozReview-Commit-ID: 3zwoZ9YpZlC
--HG--
extra : rebase_source : 25254f6dbbfbf8291fd1d6dcd194540b15da0cef
Experimenting with the shutdown sequence for Part 1 has thrown up a few edge cases that aren't yet properly handled by the session store:
- If Gecko is busy (e.g. loading a resource-intensive page), shutdown of the UI can be delayed for a bit - if the user then manually switches away from Firefox, we might get an application-background message which needs to be ignored if we're already quitting
- Backgrounding of the app while quitting can change the event ordering - the "browser:purge-session-history" notification might arrive *after* we've received "quit-application", in which case we need to flush the session history to disk again after having handled the "purge-session-history" notification.
- clearDisk() should rather delete the session store files synchronously when quitting, because otherwise there's a chance that the delete operation runs *after* the new state has already been written out
MozReview-Commit-ID: LZzGcJHxqhz
--HG--
extra : rebase_source : 9f18b99ae92a8ff0753375ea1e279df08d61640e
Convert "ClosedTabs:Data" and "Sanitize:Finished" events used in
RecentTabsAdapter and GeckoPreferences from NativeJSObject events to
GeckoBundle events.
Bug 1321418 - 1. Use GekcoBundle events in GeckoApp; r=snorp r=sebastian
Switch GeckoApp to using GeckoBundle events everywhere. UI or Gecko
events are used if the event requires the UI or Gecko thread,
respectively, and background events are used for all other events.
There are changes to some other Java classes, such as SnackbarBuilder
and GeckoAccessibility, due to the switch to GeckoBundle.
For "Snackbar:Show", we need the global EventDispatcher because the
event can be sent to both GeckoApp and GeckoPreferences. Howveer, we
only want one listener registered at the same time, so we register and
unregister in GeckoApp's and GeckoPreferences's onPause and onResume
methods.
Bug 1321418 - 2. Use appropriate JS EventDispatcher to send GeckoApp events; r=snorp r=sebastian
Change JS code that sends events to GeckoApp to use either the global
EventDispatcher or the per-window EventDispatcher.
"Session:StatePurged" is not used so it's removed. "Gecko:Ready" in
geckoview.js is not necessary because it's only used for GeckoApp, so
it's removed from geckoview.js.
Bug 1321418 - 3. Use GeckoBundle events in BrowserApp; r=snorp r=sebastian
Switch BrowserApp to using GeckoBundle events, in a similar vein as
GeckoApp. UI or Gecko events are used if the event handlers required UI
or Gecko thread, respectively, and background events are used for all
other events.
Some other Java classes also have to be modified as a result of
switching to GeckoBundle.
Bug 1321418 - 4. Use global EventDispatcher to send BrowserApp events; r=snorp r=sebastian
Change JS code that sends events to BrowserApp to use the global
EventDispatcher instead of "Messaging".
Bug 1321418 - 5. Update usages of events in tests; r=gbrown
Update cases where we use or wait for events in tests.
Currently, we stop updating closed tabs if max_tabs_undo is set to 0, however we don't clear that data and carry it around indefinitely unless the user clears the browser history.
This means that when closing a tab, we still show the "Undo close tab" snackbar, however with its contents referring to the last tab the user closed before setting browser.sessionstore.max_tabs_undo to 0.
With this patch, we clear all closed tabs (and don't reload them from disc on startup) if max_tabs_undo is 0, which also stops the snackbar from showing after closing a tab.
MozReview-Commit-ID: PEtminpW4B
--HG--
extra : rebase_source : 7c8039db1d1d7c5bc127cdc11fbc0a1387694ef9
When pressing the back button reaches the beginning of session history for a tab opened from an external app, we both close the tab and send Firefox into background. Closing the tab leads to some other tab getting selected instead - if that other tab was zombified, this means that we'll then start restoring it.
This behaviour is
- visibly distracting, as that other tab will be visible for a split second while it starts reloading before Firefox finally disappears into the background
- wasteful of resources - while restoring a zombified tab is usually done from cache, at the very least we'll waste some CPU cycles reloading a tab even though we're in background
Therefore, in this situation the UI now alerts the session store that it needn't bother restoring that other tab if it's in a zombie state. Instead, we'll restore it the next time Firefox comes into foreground - if the tab is still selected by then.
MozReview-Commit-ID: 3FcjCZrJ0Ds
--HG--
extra : rebase_source : d071884dd1e78b7da470b042e244093e797dde61
Some further post-processing happens after loading a page in reader mode, so the pageshow event is too early for restoring the scroll position.
The fix is to do the same thing that desktop does in bug 1153393 and wait for a custom event instead.
MozReview-Commit-ID: DuMA0JxnYEY
--HG--
extra : rebase_source : 4b24fedcea974cef4d916fc7e59768c160728b0c
When restoring a recently closed tab from the corresponding home panel, we normally directly switch to the freshly recreated tab. However if we've entered the home panels through editing mode (as opposed to opening a new tab with about:home), editing mode takes priority and the restored tab is opened in background instead, because we return to the originally selected tab when exiting editing mode.
To fix this inconsistency, we introduce a new parameter for opening tabs from Gecko that cancels editing mode if necessary to allow for directly switching to the new tab.
MozReview-Commit-ID: 4iqPISmtNIx
--HG--
extra : rebase_source : fab9dc911171deef1a984bd96993287d146b370a
We now do a backup copy of the session store data at regular intervals to guard against interrupted write operations damaging the main session data file.
We don't use writeAtomic()'s backupTo option, because that one works by first moving the old data to the backup file before attempting to write the new data, which might still leave us vulnerable against data loss if Firefox crashes or is otherwise forcibly terminated at precisely that moment.
MozReview-Commit-ID: Cv52rmlfmfh
--HG--
extra : rebase_source : a3ebc48970c2cd62da4c8dd34600491f58a81cb8
Currently, despite its name sessionstore.bak isn't actually a backup copy, but simply contains the last session if we aren't restoring tabs automatically and is used for powering what used to be the "Tabs from last time" section of the Recent Tabs panel.
This patch changes its filename to sessionstore.old, which frees up sessionstore.bak to be used for an actual backup copy of the current session store data.
If we are not restoring tabs automatically, sessionstore.old will be freshly recreated during each app startup by copying from sessionstore.js's contents, whereas if we *are* restoring automatically, any sessionstore.old file older than a day will be expired anyway, therefore no special migration logic is necessary for this change.
MozReview-Commit-ID: H7Gl5MQi2J4
--HG--
extra : rebase_source : 1409fb229ef851d0d0a23552427ae67803c70c7b
When we are backgrounded and Android's onPause() handler runs, we try to synchronously flush out any pending session store to storage. If however some tab events (e.g. tab closing) have been dispatched shortly before the application backgrounding, it is possible that they'll arrive at the session store after the "application-background" event. In this case, we need to process and write them to storage as fast as possible, as we can be killed at any moment now.
Therefore the delay between successive writes is completely abolished while the application is in background.
The minimum delay between a call to saveStateDelayed() and a write operation however is not completely eliminated and instead only reduced to 200 ms, so as to allow for closely following tab events (e.g. closing a tab involves both a TabSelect and TabClose event) to be batched together in one write operation.
MozReview-Commit-ID: I8q7z4kll7O
--HG--
extra : transplant_source : %DA%23%3F%82%92%1E%A8%F5%60%84U%A5%92%FAmcT%A7%D0%AA
Currently, sync writes go directly to the destination file, so an interrupted write will leave the session store data in an inconsistent state. To minimise the incidence of this occurring as far as possible, we now mimic the behaviour of atomicWrite when a tmpPath is set and write to a temporary file which is then renamed to the actual destination file after writing has finished.
MozReview-Commit-ID: 3f3z1s0hfl8
--HG--
extra : transplant_source : %A7%88y%1D%23%B6%D0%AE%BC%E54R%24%09%E1D%92%0F%8D%3C
The mobile session store saves the current document resolution in order to restore the previous zoom level when restoring a page. If the display width has changed since the session data was captured (e.g. because the device was rotated), the resolution might have to be scaled appropriately.
Currently, the session store does this scaling by itself by comparing the stored and current window widths, however this implementation is slightly simplified and doesn't cover all use cases, which means some pages can be restored at a wrong zoom level after rotation. To correctly cover all cases, the session store would have to compare viewport widths, too.
Because the MobileViewportManager doesn't wait for the session store to set the restore resolution, the latter has to call setRestoreResolution() as early as possible in order to guarantee that the restore resolution is set before the first paint of the document. Therefore the session store currently calls this after receiving a LocationChange notification. However at that time, the correct viewport for the current document is not yet available, which means the resolution cannot be recalculated by the session store at that point.
Therefore, this patch changes the approach taken and lets the MVM handle all resolution calculations instead. The session store now simply passes the stored previous display dimensions along with the previous document resolution to the MVM, which can then compare them to the current display and viewport widths and scale the resolution appropriately before using it during first paint.
MozReview-Commit-ID: IGxWw87yftK
--HG--
extra : transplant_source : e%8D%BD%26%D2%C3%8E5%E3%2B%C0t%BA%DB%C1%BBs%3F%13%1F
When restoring tabs on startup, the Java UI creates tab stubs for the tabs from the previous session. The selected foreground tab then starts loading as soon as Gecko is up and running. Meanwhile, the session store gets initialised, too and starts restoring history and other things for that tab.
After history has been restored for an active tab, the session store reloads the current history entry, however by that time, depending on device speed, page size and how many other tabs the session store has to process during startup, the initial page load might have progressed far enough to have already triggered various events monitored by the session store, e.g. "pageshow".
If those events arrive before tab restoring has finished, the session store will attempt to capture that tab's state, which will overwrite the values stored from the previous session. Once the page is then reloaded for restoring, wrong values (e.g. form data, scroll position, zoom level) might then be restored.
Therefore, we now abort any attempts to capture a tab's state
- for all tabs until the "sessionstore-windows-restored" notification has been received as a signal that the initial session restore during startup has finished
- for the restored foreground tab until the location change notification is received after reloading
MozReview-Commit-ID: HbhXcEUnRXQ
--HG--
extra : transplant_source : h%2C%DA%27%28%F0%9F%8F%15-%21F/b%18%B5%DF%F4.%BE
A tab being in a delay-loaded "zombie" state or not shouldn't have any influence on the behaviour of onTabRemove - since we remove it from the session store's sphere of influence, its __SS_data can be safely deleted anyway and whether or not a session save needs to be triggered should depend only on the aNoNotfication parameter passed by the caller.
Otherwise, with the current behaviour, the fact that those tabs have been closed will not get saved to disk if no subsequent session save is triggered through any other means (e.g. selecting a different tab, scrolling, ...) before closing Firefox.
MozReview-Commit-ID: IxjZRRutc7A
--HG--
extra : transplant_source : %3E%21%7B%3F%0Cv%01%82%AC%97%E6p%C5X%C3%90%BC%C8%D8%1B
On pages that aren't "width=device-width" or similar, Gecko adjusts the resolution when the display dimensions change, e.g. because the device has been rotated. The session store needs to do something similar when restoring a page if the device orientation has changed since the moment the tab state was captured.
Therefore, we now include the width of the browser window in the saved zoom data and use it to scale the zoom level as necessary when restoring a tab.
MozReview-Commit-ID: LBbEquO1bZ9
--HG--
extra : rebase_source : 38465ee3f16dded1d1e953fd3cdbf31b821d4777
Since we're now recording the scroll position in the session data, it makes sense to store the zoom level as well.
To do this, we make use of the new facility introduced in bug 1270019, which allows us to provide a desired initial resolution to the MobileViewportManager. For this to work, we need to send our desired zoom level before the MVM calculates the initial page resolution, i.e. before first paint/page load. Therefore, we now have browser.js notify us of location change events, so we can set the zoom level to restore early enough.
This also means that we can no longer restore the scroll position on load, because the MobileViewportManager applies the resolution we provide it via utils.setRestoreResolution() only after the first paint or page load ( whichever happens earlier). In the latter case, our JS load event handler will run shortly before the MVM has applied the desired zoom level in its own event handling code, which means that any scroll attempt which depends on the page already being zoomed in will fail to apply.
Therefore, the scroll position restoring needs to be moved to a later point in time, i.e. in this case the "pageshow" event.
MozReview-Commit-ID: 6NtYqc8pm3N
--HG--
extra : rebase_source : a6737e5c047ab2327e3a0e52c2a1176e9248a361
This copies the approach we've taken for form data saving and applies it to recording the current scroll position of the page, too.
This means that after receiving a scroll event, we capture the scroll position for the top level document and all direct child frames and include it in the session store data. Because compared to the form data input events the scroll event can fire at a relatively high rate, we throttle the scroll position capturing using timeouts to run at most twice per second.
MozReview-Commit-ID: C0lBxzHav7Z
--HG--
extra : rebase_source : 325c0f92ce003ea9026e3206b4bb101db1f037a7
There is no window in the normalData when clearing browsing history on quit with tab restore set to "never restore", which breaks the assumption made in the logging function. It also means that in that case, the current session will show up as "Tabs from last time" on next startup despite wanting to clear the history on exit.
MozReview-Commit-ID: Ft4jdomopFL
--HG--
extra : transplant_source : %A5as%14%06%1F%BD%B7c%28%3Bb%A6%A7%19U%2C%1C%2CA
Since the history restore code now apparently supports restoring subframes, too, we should let the mobile session store capture frameset navigation as well, so we can preserve the full browsing history.
MozReview-Commit-ID: 5SM8eMTfgIH
--HG--
extra : transplant_source : IO%1Bz%CA_%14%D0D%F9Q%FBA%E5S7%85%90%AE%C0
Bug 701092 originally implemented some functionality to detect successive crashes and then turn off session restore for the next start, however that functionality got lost when parts of the startup session restore code were moved to Java.
This patch re-implements this functionality within the Java UI. Unlike the previous implementation, we don't reset the crash counter in onPause(), because often enough onPause() will execute even after a crash. Instead, we check in onResume() whether our last foreground activity cycle crashed or not.
To avoid cross-process writes and reads to shared preferences, the crash reporter no longer sets the relevant flags in GeckoApp's shared prefs directly, but instead writes an empty CRASHED file to the Mozilla directory as a flag, which is then checked for by the main process during startup.
Alternative solutions considered were:
- Using Context.MODE_MULTI_PROCESS for accessing the shared prefs. Works, but forces the shared preferences to always be re-read from storage and is also deprecated from API 23 onwards.
- Using a ContentProvider for managing the cross-process shared prefs as suggested in Google's documentation. Seems somewhat over-engineered for this use case.
- Sending a broadcast from the crash reporter to signal the main process, so it can update the relevant shared prefs from the correct process. Doesn't work reliably immediately after crashing - sometimes the broadcast never arrives.
- Setting the crash flags directly in the crash handling functions in GeckoAppShell. Could work even when not building the crash reporter, however doesn't work easily for native crashes, because those are handled internally by Gecko without going through the Java crash handling code.
MozReview-Commit-ID: 6g7AmnJhoQk
--HG--
extra : transplant_source : %C2%F28%D9%8A8%08%C6%9F%A4%03%D7%EC%81F%B9%21%3A%E2x
The logging can be enabled by setting "browser.sessionstore.debug_logging" in about:config.
MozReview-Commit-ID: DCJevcsg549
--HG--
extra : transplant_source : %E3%166%F7%0C%29%C0%FB%0A6E%02Sd%10%9D%9A%5DN%7D
As long as a tab is kept in memory, Gecko handles restoring of the form data during forward/back key navigation internally without involving the session store. After going back/forward, OnTabLoad() is triggered, which throws away the previous session store data for that tab and recreates only the session history part of it. Form data is only captured in OnTabInput(), which means that if Firefox is killed or the tab closed/zombified before the user interacts with the form (triggering input events), form contents won't be captured by the session store and will therefore get lost.
MozReview-Commit-ID: LmZlYrHjw6k
--HG--
extra : transplant_source : %3B%8B%E5%83%CE%EB%FC%25%B7yq%D3%19%10%8F%85%0A%8Do%B7
Previously, when restoring a tab, we made a copy of the whole session data from which we would then extract and restore the form data - if present - after page loading had completed.
With the changes from bug 852267, the original session data - containing any eventual form data - is now always reattached to the restored tab object, therefore we no longer need to make a copy of it. Instead, OnTabLoad() has been adapted to preserve the formdata if it is needed for restoring later on.
MozReview-Commit-ID: D9fQxtVnuZe
--HG--
extra : transplant_source : pl0%21%2C%8C%07Y%8E%5D%D5%F8wa%2A4%DBU%B5%9F
The session store relies on a few event listeners to track the history and life cycle of a tab. Under memory pressure, background tabs are zombified in order to reduce our memory usage. This involves destroying the original tab object and then recreating it as a delay loaded tab.
As the session store is never told about this, it will keep the event listeners for the old tab objects - which have now been destroyed - alive and won't receive any future events for the new tab objects. This means that once a zombification has been triggered, the session history for those tabs will become effectively frozen, so after the next zombification or a session restore, the tab will reload the wrong page.
Therefore this patch introduces two new events which are sent during the tab zombification process and allow the session store to detach its event listeners from the old tab object before it is going to be destroyed and subsequently reattach its listeners to the new tab object.
MozReview-Commit-ID: 6xZtsCNZbQY
--HG--
extra : transplant_source : %7D%BB%D6%BA%D9%F6%B8%0E%7D%F6%0A%26%A0Y%3E%1Dr%7B%F1%C5
Normally we shouldn't get into a situation where aTabData will be null/empty when trying to restore history, but bug 1229259 comment 10 shows that this can somehow still happen, most probably because we zombified a tab before it had any chance to build some session data.
MozReview-Commit-ID: 9Mw55NTiVTP
--HG--
extra : transplant_source : %F5%CE%C5%89%E0%3F%3E%F3%23e%AE%1C%DE%117%B4eE%D0%3B
Up till now, when restoring tabs, the previous session store data was only attached to the tab object where necessary to make delay loaded tabs work. In all other cases, the session store data was left empty and recreated only once page loading had progressed sufficiently far to fire the DOMTitleChanged event. This means that a tab could get lost if the session was saved before this point and Firefox then subsequently killed. In conjunction with bug 1044556, a memory pressure event could also prevent the session store data from being recreated for a tab, because the session store wouldn't recieve any new events for tabs that had been zombified.
Therefore, with this patch we always attach the previous session store data to a freshly restored tab, so it will always be included in a session save even if the save is triggered before tab loading has progressed far enough.
MozReview-Commit-ID: GVupnXwuRDV
--HG--
extra : transplant_source : %AAsbW%B6%10%3A%E9%F1.J%9D%E8W%40%AD%CCkI%1D
Be warned. Do not attemp to change the .js "test" source code in ./js
They are meant to check
- the outdated 0666 octal constant is still parsed correctly,
- the outdated 0666 octal constant raises syntax error flag
in strict mode, etc.
So leave them alone.
I did as much conversion to "real Javascript" as I could stomach. It
is, unfortunately, not feasible to remove all preprocessing from CSS
and XHTML files.
--HG--
extra : rebase_source : 8fb3601d09010d9efa4fa33b507dc327fe4dca47
extra : amend_source : 5f796e7cc131880b12756e17240396b040ae981c
