We want to be able to detect when we've opened a reader view item. Note: this is
independent of whether or not we're in the Reading List smartfolder: it's possible
to open reader view bookmarks from any real bookmark folder, or the smartfolder.
MozReview-Commit-ID: KhqclodWSji
--HG--
extra : amend_source : 96460a430de900920dc2858dc171544657771abb
That way, the section headers (e.g. "Today", "Yesterday", "Last 7 days" etc.) blend better with the following item.
The correct hiding of the divider depends on the view type reported for the respective RecylerView child items. Because the view type is stored a simple number, this means that any other RecylerView wanting to use this divider decoration implementation must use the same item types as the history panel in order to remain compatible, otherwise the divider could be unexpectedly hidden. Therefore, we rename the DividerItemDecoration to underline its intended usage scope.
MozReview-Commit-ID: 8JUS6ke3RBL
--HG--
rename : mobile/android/base/java/org/mozilla/gecko/widget/DividerItemDecoration.java => mobile/android/base/java/org/mozilla/gecko/widget/HistoryDividerItemDecoration.java
extra : transplant_source : %E8%B7%8E%9F%C9%E5%CCmX%22r%D7%D2%8A%DF%2A%D0%83%9Bw
Just watching for a SessionRestoreException during startup can introduce some false positives, because that exception is triggered in any case where we can't restore tabs, not just when the session file has been damaged, e.g.:
- on first startup
- on builds affected by bug 1228593, users who are (theoretically) restoring their tabs, but clearing their history on exist end up with a deleted sessionstore.js
- should we implement bug 1275662, we'd hit that exception in that case, too.
Therefore we only send the telemetry event if we hit that exception even though a sessionstore.js file is present. We also exclude the case where the file size of sessionstore.js is 14 bytes, because that is most likely corresponding to a file containing only {"windows":[]}, which means that the session store intentionally wanted to write a file containing no tabs.
Currently this is only the case for users who are clearing their history on exit and are also *not* restoring tabs, however if bug 1275662 should get implemented, we'd probably encounter those empty files for users who have their restore setting set to "Always restore", too.
Because of bug 1261008, we can also end up with no restored tabs (and a SessionRestoreException) if the session file contains only about:home tabs with no history, because we're skipping those and not restoring them. To detect that case and exclude it from telemetry, we have to include additional logic within the SessionParser instance used during startup and pass those results back to the calling site in GeckoApp.
MozReview-Commit-ID: 6pAhDU3d8QA
--HG--
extra : rebase_source : ebf4d902a616c17ba10c645ad8ef469ceafe8cce
We were incorrectly retrieving the cookie from the notification intent
and passing that along which affected the invocation of the notification.
MozReview-Commit-ID: FxL8sw6lByJ
--HG--
extra : rebase_source : 503ab15c58b9403851477b380ffe7ac3bd2f7215
extra : amend_source : 8dd88a72795184f825a1e43f0cb163691cf97181
Add a check to showSoftInput and hideSoftInput To prevent an infinite
recursive loop of showSoftInput indirectly calling
onCreateInputConnection, which calls showSoftInput again,
SafeReceiver is responsible for registering LocalReceiver with a LocalBroadcastManager.
SystemReceiver is responsible for handling BOOT_COMPLETE and EXTERNAL_APPLICATIONS_AVAILABLE intents.
LocalReceiver is responsible for handling passed in Stumbler preferences (enabled state, API key, user agent).
StumblerPreferences are now sent using LocalBroadcastManager, avoiding any possibility of leaking API key.
MozReview-Commit-ID: J8pRN6pbLOg
--HG--
rename : mobile/android/stumbler/java/org/mozilla/mozstumbler/service/mainthread/PassiveServiceReceiver.java => mobile/android/stumbler/java/org/mozilla/mozstumbler/service/mainthread/LocalPreferenceReceiver.java
extra : rebase_source : 0f11bb5aa38c27849f1a4f35ed51bdf259c418c8
Also fix that the default merge dir in the mach command creates a directory
that's the merge make target, and thus keeps that make target from actually
running.
MozReview-Commit-ID: HWZBPxWuHSy
--HG--
extra : rebase_source : a39157ad9eb99f3eef5d149d003e62a235f92fc1
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
Add a loadUri method in GeckoView that replaces the functionality of the
current LOAD_URI event in GeckoEvent, and make GeckoApp and BrowserApp
use the new call.
The implementation for loadUri differs from the previous implementation
of LOAD_URI by directly calling nsIBrowserDOMWindow::OpenURI, instead of
going through the command-line handler. This more direct approach lets
us get rid of the Fennec command-line handler entirely.
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
This is Deepthi Venkitaramanan's patch with feedback comments addressed.
MozReview-Commit-ID: 7vs0ZgefOVy
--HG--
extra : rebase_source : b45ded1517cf05acb04778219cd5860c1afdfcb5
This removes the unnecessary setting of c-basic-offset from all
python-mode files.
This was automatically generated using
perl -pi -e 's/; *c-basic-offset: *[0-9]+//'
... on the affected files.
The bulk of these files are moz.build files but there a few others as
well.
MozReview-Commit-ID: 2pPf3DEiZqx
--HG--
extra : rebase_source : 0a7dcac80b924174a2c429b093791148ea6ac204
As of the writing of this patch, NSSDialogService pops up a prompter on
Android as follows (assuming at least one label is requested):
1. NSSDialogService.js calls Prompt.jsm methods and eventually requests the
prompt be displayed.
2. Prompt.jsm sends a messages to the Java side.
3. The Java side receives the message and eventually calls
org.mozilla.gecko.prompts.PromptInput.LabelInput.getView().
4. LabelInput.getView() calls android.text.Html.fromHtml().
At no point is any HTML injection prevention done, so in theory NSSDialogService
could be an injection vector.
In practice, it appears that fromHtml() doesn't actually allow anything malicious
to be done. This patch introduces HTML escaping at the NSSDialogService
level just to be safe.
MozReview-Commit-ID: LhHuZKSqx01
--HG--
extra : transplant_source : l%C9%A2%95%9A.%05%1F%CF%5D%02%5E%12N%C1%B7O%7C%1B%8B
By changing the Interpolator to be linear instead of decelerating, we should
see an animation with constant speed. I've also reduced the animation time
from 250 milliseconds to 150 to give it a snappier feel.
MozReview-Commit-ID: LBsdxG0lyvX
--HG--
extra : rebase_source : ef2f1fb0d9e18ce4f23932355e40888355411b36
extra : amend_source : f9f1a0763ac785c4e115a5be78fddb7a83000270
When launching fennec while device is offline, we would often not send these events to Gecko,
and it wouldn't know to load tabs from cache. sendEventToGecko would queue up our events for us if GeckoThread isn't
in the RUNNING state, so let's rely on that mechanism instead. It's possible that we will have a succession of network
state events which aren't valid by the time they're actually sent, but as long as event queue is FIFO, it should be ok.
MozReview-Commit-ID: BCiO2EozUnx
--HG--
extra : rebase_source : 3935444f69be9171aa60a8f4b3e5db29035ecb6c
registerReceiver returns the first sticky intent which matches our filter, or null
if there aren't any. Remove the log statement about "failed registration", since null just
means that we haven't had any sticky broadcasts for this filter yet.
MozReview-Commit-ID: KA2Rxt2fk2T
--HG--
extra : rebase_source : 37adcb2a240f36466a95bc34c904dece422e9bbd
By default, i.e. for most lists in the homepanels, we want to open the offline reader-view version
of a page if the page is stored as an offline reader-view bookmark (TwoLinePageRow shows the bookmark
and offline status for pages, not only in bookmarks, but also in the list of top sites, awesomescreen
results, and history). The only exception is the topsites grid, where we don't offer any indication
of the bookmark or offline status of a page. For now the expectation is that topsites open the
normal version of a page, so we need to bypass the usual flow for that case.
(It's possible the UI around this would change in future, but with the current UI this is probably
the most obvious / least frustrating behaviour.)
MozReview-Commit-ID: BMpGG4KQ62w
--HG--
extra : rebase_source : a223304451e46e1c0429c5b3bcd9be6d43bf9428
extra : amend_source : 462ea5b54781fd8c534a4a4a484fd60714e3f40d
For now, this event is only going to be used to cover a narrow edge case around
display of the "Showing offline version" snackbar, so let's not overthink it.
MozReview-Commit-ID: Cd9q7kwnjjQ
--HG--
extra : rebase_source : ebf8656565fef1b6969fb89de20fdd62a64e5043
This issue has been fixed in the latest Android N preview, we should
remove the workaround to simplify the code.
MozReview-Commit-ID: 6xwIA5QzzhQ
--HG--
extra : rebase_source : dc84f80591ffe2fe779c1649f15376cc29d32662
