Remove SENSOR_EVENT from GeckoEvent and implement it as a native method
in GeckoAppShell that is invoked by the sensor event listener in
GeckoAppShell.
Implement SensorEventListener directly in GeckoAppShell instead of
indirectly through GeckoInterface and GeckoApp, because the
SensorEventListener consumer is in GeckoAppShell.
Because we can't actually rotate the emulator within the test, we just manipulate the session store's stored display size to pretend that the device was rotated between tab data capturing and restoring.
MozReview-Commit-ID: L2HzTLHcBQu
--HG--
extra : transplant_source : %5D%E1%08i%15%E8%14nu%EC0%F8-%B4%3B%0D%11_%13%B3
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
Needed because buildbot clones/checks out from the repo head (of default)
and then updates to the rev for the nightly we're pulling, which can cause
CLOBBER file changes to initiate an unwanted clobber of the object directory
where we just pulled the nightly binary from. Even when CLOBBER hasn't actually
been touched in the changeset range we're looking at between nightlies.
MozReview-Commit-ID: 154d2iZeHgd
--HG--
extra : rebase_source : 504b821955a870cabf6fc727d13e44a33aabb45c
If the browser is set to always restore the session (default) then we will never
start with an empty session. Even if the user closes all tabs we will re-create
a new tab pointing to about:home. So we will always at least restore this tab on
the next startup. As a consequence we will never open the 'homepage' on app start
because we will never have a non-empty session.
With this patch we won't restore tabs that point to about:home and do not contain
any other history. As a result we might restore an empty session and load the
homepage or about:home (depending on configuration) in a new tab.
In case we decide to not restore the currently selected tab, we just select the
first restored tab if there's any.
MozReview-Commit-ID: DuN03M60Gi8
--HG--
extra : rebase_source : 92ec12d32dfe62ebb0e7ae8e299f579dcd8c1a84
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
After bug 1249201 landed, the "visibilitychange" reason wasn't
dispatched during scrolling anymore. See bug 1249201 comment 44 for the
reasoning.
MozReview-Commit-ID: AhHiWeR2fq7
--HG--
extra : rebase_source : 368942f3f08f305524de8a65c16cc12a702410f4
The intention is that GeckoView consumers will not use browser.xul,
but instead geckoview.xul; and that they'll provide content URLs from
their assets/ directories. This lets them do things without modifying
the omnijar and in particular without setting Gecko's prefs *before*
Gecko startup.
MozReview-Commit-ID: 2QLQQ5RphFu
--HG--
extra : rebase_source : b80eb1b15a54dac3c19ba9c7bfe4f0ac7dae78c6
If PushService has not been created when getInstance is called, create
the PushService instead of throwing an error. This fixes a possible race
condition between initializing PushService and receiving a push message,
where we can receive a push message first.
The only platform for which this change is *not* a no-op is Mulet. Last time
I checked Mulet worked fine with APZ enabled but there were a few test failures.
Now I don't believe it's running in automation anyhwere so that shouldn't be
an issue. If it is, they can re-disable APZ easily enough if needed.
MozReview-Commit-ID: 5xKUuTOnubM
