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
Also fix a typo in a comment, "Rules" -> "Rulers"
MozReview-Commit-ID: Gy5k3TR9JDM
--HG--
extra : transplant_source : i%15%1B%A1L%F9%B9%23%CC%F70u%0AT%0C%B4%27m%B2%DF
Also tidy up the HTML a bit by removing errant <img> close tags
MozReview-Commit-ID: 4cmtW1S2BI8
--HG--
extra : transplant_source : %26%E6%FE%BB%FE%2A%CCG%E0%27%3B%3DYK%2BP%E7%9D%C7%C9
When trying to load or unload FRAME_SCRIPT into a process we should check if we have
messageManager available to do the work or error accordingly.
MozReview-Commit-ID: 1xonnY34vI3
--HG--
extra : rebase_source : 61e681785c13e4096ca235e81f676552b9e1a629
Per froydnj in bug 1186064 comment #23, "it makes sense to proceed with removing
MSVC 2013 support." This commit does that.
We also go a step further and require VS2015 Update 2 instead of just
update 1. This temporarily brings us down to just 1 officially supported
Visual Studio version. However, VS2015u3 was just released and is
unofficially supported.
Since MOZ_CRT is no longer set, references to it have been removed.
MozReview-Commit-ID: 8MUR6qLzQA5
--HG--
extra : rebase_source : 8f5061080a3d56dd484f9be03649fb65f0145f67
