If the src is too long, we crash!
To test this, you can use my test page:
https://people.mozilla.org/~mcomella/test/base64.html
An alternative approach would be to prevent users from sharing base64
images altogether because the experience is slightly jarring (since the
base64 string is copied to the application rather than the image).
MozReview-Commit-ID: AQeQ0Ff6ZMB
--HG--
extra : rebase_source : f265c9c474adaeaef9dd50bde5b9f80c6d5b0f53
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
Parsing the session store JSON data to restore the last session's tabs is both
- computationally relatively expensive
- involving disk I/O
therefore, we shouldn't be doing it on the main thread.
To make sure the session data is actually ready, subsequent code running from a different thread that needs to access it (loading the startup tab, the Recent Tabs panel reading the "Tabs from last time") checks that session store data processing has actually finished and waits if necessary.
MozReview-Commit-ID: EYf1fdglIrA
--HG--
extra : transplant_source : %0D%60F%B0%16%DF%7E%03%CEL%F9%15G%E0%8E%8Fl%21%EEZ
For session data parsing, we need to know whether we were invoked with an external URL or not. Since we want to move session data parsing forward to an earlier point in time, but also continue needing that external URL info during initialize() as well, we'll factor out those calculations into their own functions which can then be called from both places.
MozReview-Commit-ID: HFlT8uxC9yz
--HG--
extra : transplant_source : %A4%AE/%F5%00P%89%95N%033%F3%C6%0E%98%A4%8A%9F%B6%2A
Android Studio doesn't recognise our version guards and is consequentially always showing two errors in GeckoApp, which makes it more difficult to spot when you've introduced an actual error.
MozReview-Commit-ID: LpNIwHOhEWE
--HG--
extra : transplant_source : %22%86%80q%1E%CE%FE%B1%16%BF%40%DF%C0%0F%5D%CB%E0%F8%A0%8A
Delay initialization of PushService and DLC in GeckoApplication to after
the Gecko:Ready message. That way, hopefully they give up some CPU time
to other initialization tasks.
Restoring a tab from the Recent Tabs panel, which goes via the session store's _restoreTabs() function and ultimately via BrowserApp.addTab() and a Tab:Added message back to the Java UI requires the value for isPrivate to be present in the session store data for the respective tab - if it isn't, we end up sending isPrivate as "undefined", which breaks the process of adding the new tab in our UI.
When the session store collects the full tab data for a browser, it always includes the values for isPrivate and desktopMode, therefore we now include those values in the basic session store data we use in initialising a new tab object, too.
MozReview-Commit-ID: 5BZ9PL7xDWA
--HG--
extra : transplant_source : %01%8B%E7%1Asg%FF%D8%DC%07%21Ly%F4%9A9Q%B9%00O
