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
- Use Content:PageShow event to inform Tabs that they were actively loaded from cache
- Move offline notification logic away from browser.js and into a delegate, which displays notifications when
tab in question is user-visible
MozReview-Commit-ID: 2qCACHyWOlp
--HG--
extra : rebase_source : 457a42ebba5cfc32ab7dabce0a8a11d6511b9c08
This provides implementations of ChooseCertificate() with more flexibility, and
allows callers of ChooseCertificate() to be less complex.
A portion of this work involves reimplementing
nsNSSCertificate::FormatUIStrings() in JS and improving UI strings for l10n.
MozReview-Commit-ID: CE7Uc2ntwmZ
--HG--
extra : transplant_source : R%A8eC%CEO2%DC%20%F7%B4V%F3g%E6h%EB%D5%8D3
This fixes the following in the IDL:
1. Misleading or unclear parameter names in the IDL. |cn| in practice is the
concatenation of the CN of the server cert and the port of the server, and
|issuer| is the Organization of the issuer cert of the server cert.
2. Use of the |wstring| type. |AString| is generally preferred, and has the
benefit of letting implementations skip null checks due to the use of
references.
3. Using an explicit |canceled| outparam instead of just setting a return type.
There is no need for the outparam if the return type can be used.
4. Using |long| (int32_t) for |selectedIndex|. |unsigned long| (uint32_t) is
more logical, and paves the way for future changes.
This fixes the following in the Android implementation:
1. Lack of checks to ensure the QueryInterface() call succeeded. In practice,
the call will always succeed, but it's good practice to check anyways.
2. Setting a variable to an nsIPrefService instance initially, then later
setting it to a pref branch instance later on. This is confusing and
unnecessary.
This fixes the following in the desktop implementation:
1. Lack of null pointer checking.
2. Trying to get a parent window ref off a context that doesn't actually support
doing so.
3. Setting a variable to an nsIPrefService instance initially, then later
setting it to a pref branch instance later on. This is confusing and
unnecessary.
4. Abusal of the CAPS bundle.
5. Unnecessary variables.
6. Variables declared far away from where they are used.
7. Variable shadowing.
8. Style issues.
9. Lack of documentation.
This also fixes the following:
1. Lack of localisation notes.
MozReview-Commit-ID: FTc6XecJd6h
--HG--
extra : transplant_source : %ABQ%8F%E6%A3%25%FE%94%E4%D6X%3D%28%2C%05%5E%FB%84.-
This fixes two issues:
1. Passing a literal 1 as the |length| argument to formatStringFromName(). This
is obviously incorrect and should instead be the length of the given arg
list.
2. Directly setting the |selectedIndex| outparam to a number. XPIDL outparams
on the JS side are actually objects that wrap the true outparam value, which
must be accessed via |.value|.
MozReview-Commit-ID: BJObQfcV5G7
--HG--
extra : transplant_source : %11%B2TD%F5%C3%84%BD%C1%7B%3B%1Em%EC%CA%CAu%E5%3Dq
If the main thread has to wait for the session data parsing to finish - which is more likely when you've got many tabs open, meaning a large sessionstore.js file - it does so on "this", i.e. GeckoApp.
The session data parsing itself is done from within a Runnable, so we need to qualify "this" there if we want it to refer to GeckoApp itself, so we can successfully release any waiting threads through notifyAll().
MozReview-Commit-ID: 3LhJsI5rNU3
--HG--
extra : transplant_source : %27%27X%9CTm%A6%88%3F%1B%8Cm%0E4%F1%9D%9B%E5%F2%28
Currently this service does not implement any of the callbacks. However it is
necessary to be detected as an app supporting custom tabs.
MozReview-Commit-ID: Hz99Gp9aQCX
--HG--
extra : rebase_source : b73730f5c4d497e4fef5ed9bab3ae1c50e43de61
This activity doesn't do much yet and just has a layout including a GeckoView.
Some basic behavior from GeckoApp is working though: Context menus, floating
text selection, snackbars.
MozReview-Commit-ID: C6SJeYz609h
--HG--
extra : rebase_source : c65d8657ed795365b81c9bfeda41ac814760db8d
We will need to dispatch Intent objects to different destinations (Browser, Custom Tab and eventually
progressive web apps).
The logic of TabQueueDispatcher is folded into this new activity.
MozReview-Commit-ID: 3P4eIvtAKEW
--HG--
extra : rebase_source : 3d7604a7bdbd2ea80602313e7bc66212a089994b
Build slaves on automation are based on Centos 6, which doesn't have a
recent enough version of libstdc++ for our new requirements. But since
we're building with a recent GCC or clang with its own libstdc++, we do
have such a libstdc++ available somewhere, and the compiler picks it
when invoking the linker.
Problems start happening when we execute some of the built programs
during the build, like host tools (e.g. nsinstall), or target programs
(xpcshell, during packaging). In that case, we need the compiler's
libstdc++ to be used. Which required adding the GCC or clang library
directory to LD_LIBRARY_PATH.
Unconveniently enough, the clang 3.5 tooltool package we're using for
ASAN builds until we can update to at least 3.8 (bug 1278718) doesn't
contain libstdc++.so. So for those builds, pull the GCC package from
tooltool as well, and pick libstdc++ from there.
Before introducing the folder count, the bookmark folder icon
was set as the drawable on a TextView. This actually resulted
in scaling that doesn't preserve the aspect ratio. To reproduce
this in the new ImageView (added when we switched to a two-line
folder layout), we simply need to set the icon size explicitly
and scale to fit the whole area (as opposed to setting two
constraints and fitting while preserving aspect ratio).
The folder/reading-list icons are unaffected as they already
have the expected aspect-ratio, the back-arrow is now scaled
as expected.
MozReview-Commit-ID: Fl5JY3Lznau
--HG--
extra : amend_source : f3ad6cddd9a162953913b3161b9a5ceea6d3e15e
We're now calling setIntent on the background thread. The onTargetSelected callback expects
to be run on the UI thread, and it looks like Android hangs up when we call UI methods
on the background thread. This in turn means the entire background thread gets locked up
(we execute tasks on the background thread sequentially) and no further background runnables
are executed. This breaks anything else requiring use of the background thread, e.g.
favicon generation, search, permissions doorhangers, etc.
MozReview-Commit-ID: CoYUOMqNX0m
--HG--
extra : rebase_source : 84a4dcc8a8aad590f02ba9f8d8b2564922787d17
In this patch, I move the telemetry server preference from app preferences
to per-profile preferences. We never allowed the user to set the preference
so this should cause no issues.
MozReview-Commit-ID: 7D5y58R2ejd
--HG--
extra : rebase_source : 3b4214968cac48150f6a3f873967cb43c7952b1b
Edge case: the admin profile can disable health report upload for themselves
but (I assume) the new profile won't automatically match these settings. While
I'm not sure if this is even possible, it's outside the scope of this bug.
MozReview-Commit-ID: 1SkXhL7B5xb
--HG--
extra : rebase_source : 95540b8b76f7014544022c7cb0880791ac536721
DB access happens deep in the internals of setting a new Intent for our
ActionProvider. Posting this to a background thread here seems to be the simplest
option to ensure correct threading.
MozReview-Commit-ID: 3iS8w5Cxf02
--HG--
extra : rebase_source : 48c90e5fa47a470d3360dbd44dc97111aac5ff3e
It's possible there are more UI-thread DB accesses lurking. To avoid maintenance burden
we should therefore enable this assert only in debug builds - releases will be
unaffected, but we can still notice incorrect DB access during development.
MozReview-Commit-ID: Kgzf1L3WjIE
--HG--
extra : rebase_source : b1f9f01ea746c005a038693aaa5eddb2bb103a2b