Android does not currently have anything similar to a 'required' state
to indicate that a field or input is required before submission. In this
patch we append a localized "required" string onto the node's hint.
The hint typically has the description of the node. If the node is an
entry the hint will have its label followed by the description.
Differential Revision: https://phabricator.services.mozilla.com/D65215
--HG--
extra : moz-landing-system : lando
MANUAL PUSH: More broken stuff I accidentally fixed.
--HG--
extra : rebase_source : fc41c2a97f38b3ed86efe046fca7bb780440a9dc
extra : amend_source : c6c6b373f0a8fbd3f45415d3cef7417720d353be
Before this patch, the TabDelegate was "special" as in it had just one global
delegate that receives events for all extensions and sessions. This was done to
allow mochitests to call tabs.create and tabs.remove.
This hack is no longer needed as now we can notify the embedding layer that a
new extension has been installed and we have a way to list currently installed
extensions.
This patch makes TabDelegate behave the same as the other delegates
(ActionDelegate and MessageDelegate) and will allow further simplications of
the WebExtension Delegate code.
Differential Revision: https://phabricator.services.mozilla.com/D64799
--HG--
extra : moz-landing-system : lando
|get domFileOrDirectory| is sync so we cannot return a promise from there. We
instead resolve the DOMFile before returning from the file picker callback
which is async already.
Differential Revision: https://phabricator.services.mozilla.com/D65193
--HG--
extra : moz-landing-system : lando
Occasionally, we might try to apply synced bookmarks when a transaction
is already in progress. Consider something like this:
1. The user clicks the star button, which adds a bookmark to the
default folder. Under the hood, this runs a transaction to
completion—`BEGIN`, some `INSERT`s and `UPDATE`s, then `COMMIT`.
2. The `item-added` observer notification kicks off a sync.
3. The user, with the star UI still open, picks a new folder for the
bookmark. This moves the bookmark under the hood.
4. To move the bookmark, we run `BEGIN` on the Places connection's
async thread. Remember, `Sqlite.jsm` runs async statements one at a
time.
5. Concurrently, the merge runnable is scheduled on the async thread.
It's not aware of the `Sqlite.jsm` transaction queue, and doesn't
know that a transaction for the move is already open.
6. The merger tries to open its own transaction with `BEGIN`, fails
noisly, and returns a "cannot start a transaction within a
transaction" error back to the main thread.
7. The move transaction started in (4) runs to completion, updating
the new bookmark's parent and committing the changes.
This is a case of bad timing—retrying the sync once the user finishes
making changes will work—but reports errors in telemetry and logs.
This commit downgrades those to warnings.
Depends on D63732
Differential Revision: https://phabricator.services.mozilla.com/D63734
--HG--
extra : moz-landing-system : lando
Previously, `mozIStorageConnection#transactionInProgress` returned true
only if a transaction was started via `beginTransaction()`. This meant
that manually executing `BEGIN`, as `Sqlite.jsm` and the Rust bindings
do, wouldn't accurately report if a transaction was in progress.
Similarly, the flag wasn't accurate in cases where SQLite automatically
rolled back a transaction.
Fortunately, SQLite provides the `sqlite3_get_autocommit()` function,
which we can use to determine if a transaction is open or not. This
commit refactors the `transactionInProgress` getter, along with all
`Connection` methods that depend on it, to use the SQLite API instead
of managing that state on the connection. `mozStorageTransaction` and
`Sqlite.jsm` still use their own flags to decide whether to commit
their transactions, for reasons explained in the IDL comment.
This commit also moves `transactionInProgress` to
`mozIStorageAsyncConnection`, so that `Sqlite.jsm` can use it, and
exposes it to Rust.
Differential Revision: https://phabricator.services.mozilla.com/D63732
--HG--
extra : moz-landing-system : lando
In current implementation of Drain(), we use the Flush() method of remote
decoder to restart it so that the decoder can accept new input again. This
will force the decoder to drop all internal buffers, including those that
are not rendered yet. Since Flush() is called after Drain(), there is no need
to do that internally.
Differential Revision: https://phabricator.services.mozilla.com/D63912
--HG--
extra : moz-landing-system : lando
Replace the INTERPRETED/INTERPRETED_LAZY flag with BASESCRIPT/SELFHOSTLAZY
flags. This delegates more of the responsibility onto the BaseScript itself
and will allow us to combine the lazy and non-lazy script instances in a
single BaseScript.
The choice of these flags corresponds to the union-arms of JSFunction. This
simplifies reasoning in the JITs as well.
Differential Revision: https://phabricator.services.mozilla.com/D65032
--HG--
extra : moz-landing-system : lando
In order to stop relying on the JSFunction flags to determine if a function
is currently lazy, we need to remove uses of JSFunction::hasScript,
JSFunction::hasLazyScript, JSFunction::isInterpretedLazy.
Uses of hasScript() can be replaced by a new JSFunction::hasBytecode()
method. To use this method we need to ensure the function is not incomplete
(marked as interpreted but missing the script). This is often implied by the
context, but care must be taking if the function came from iterating GC
arenas.
Uses of hasLazyScript() can be replaced by checking for hasBaseScript() and
the lack of hasBytecode().
Uses of isInterpretedLazy() are replaced by checking for isInterpreted() and
the lack of hasBytecode(). This differs from hasLazyScript() because it
includes the SelfHostedLazyScript case.
Differential Revision: https://phabricator.services.mozilla.com/D65031
--HG--
extra : moz-landing-system : lando
These checks are reliant on the details of current lazy-script handling and
interfere with removing the INTERPRETED_LAZY flag so remove them for now.
Differential Revision: https://phabricator.services.mozilla.com/D65030
--HG--
extra : moz-landing-system : lando
Previously, text input controls weren't font inflation containers simply by
virtue of being "display:inline" by default, which automatically makes them in-
eligible for becoming an inflation container.
As of bug 1539469 this has changed however - those <input> elements are now
"display:inline-block" by default, which with the current font inflation logic
turns them into font inflation containers.
This leads to a few problems:
1. The logic from bug 708175 (stop inflation if there is a size-constrained non-
inline frame in the chain from the current frame to their font inflation
container) is built on the assumption that the (possibly size-constrained)
form control itself isn't a font inflation container.
2. When form controls end up as font inflation containers themselves, they no
longer size themselves properly to match the size of their inflated
contents, because they are now subject to the AutoMaybeDisableFontInflation/
mInflationDisabledForShrinkWrap logic which ends up disabling font inflation
during the size calculation of the form control.
1.) means that we now inflate some text inputs that we didn't use to inflate
previously and 2.) means that every time we attempt to inflate a text input, we
end up with the text content being inflated, but the containig box being not and
therefore too small.
Because of this, as well as because
1. The introductory comment in nsFrame::IsFontSizeInflationContainer itself
mentions that form controls aren't expected to be inflation containers.
2. There is the precedent from bug 786946, where <select> elements were
specifically excluded from becoming font inflation containers when their
default display style was changed from "inline" to "inline-block".
all of this points towards having to specifically preclude <input> elements
from becoming font inflation containers as well.
Differential Revision: https://phabricator.services.mozilla.com/D64908
--HG--
extra : moz-landing-system : lando
One of them used to pass accidentally (due to a bug that the previous patch in
this bug fixes).
The other one is now passing.
MANUAL PUSH: Fixup expectations for a patch that fixed select rendering on Android
--HG--
extra : rebase_source : 8fd39f8971493ea9b7ce0509f46099e4ea4f1b72
extra : amend_source : 2094f77a54c5af3649f5efcffc03eb0f82364321
Add a version of GeckoSession.reload that takes LOAD_FLAGS_* so
that it is possible to bypass caches and proxies on reload.
Differential Revision: https://phabricator.services.mozilla.com/D64809
--HG--
extra : moz-landing-system : lando
MOZ_PROFILE_GENERATE is already defined in mozilla-config.h and doesn't
need to be re-defined by the moz.build files.
Differential Revision: https://phabricator.services.mozilla.com/D65210
--HG--
extra : moz-landing-system : lando
Rather than treating webrender::intern::UpdateList as a sequence of operations,
each of which might be an insertion or a removal, and using a side table to
supply extra data for insertions, it's simpler to segregate insertions and
removals into two separate vectors. This avoids the need for an enum whose
discriminant needs to be checked within the loop, and allows a few loops that
are only looking for one kind of operation to skip over the others entirely.
Ultimately, there should be no change in the order in which operations occur. In
practice, the old UpdateList always held a contiguous run of insertions,
followed by a run of removals (removals are consumed by apply_updates directly
after being generated by end_frame_and_get_pending_updates).
Differential Revision: https://phabricator.services.mozilla.com/D64444
--HG--
extra : moz-landing-system : lando
Reuse the AddXULMinSize logic which already deals with all the widget stuff,
non-themed scrollbars, etc.
Remove some useless margin declarations and such in GeckoView scrollbars code
now that AddXULMinSize does look at the min-width/height properties.
Differential Revision: https://phabricator.services.mozilla.com/D65129
--HG--
extra : moz-landing-system : lando
This class is not technically the thread itself, it's the runnable that the
sampling thread uses. This name is more accurate and clear for it.
Differential Revision: https://phabricator.services.mozilla.com/D64753
--HG--
extra : moz-landing-system : lando
Currently we only profile the Java Main Thread, and don't profile anything
else. This is not ideal, but this is how it works right now. And inside the
code index `0` was hardcoded on the most parts of the code. We can rollback
this patch once we want to implement profiling more than one thread, or we can
think about something more clever.
Differential Revision: https://phabricator.services.mozilla.com/D64752
--HG--
extra : moz-landing-system : lando
In the current Win 8.0, these functions both start with a RIP-relative JMP (6 bytes) followed by 6 nops (6-bytes), which does not give us the 13-bytes we need for a trampoline so we require the trampoline to fit into 10 bytes.
Differential Revision: https://phabricator.services.mozilla.com/D63260
--HG--
extra : moz-landing-system : lando
Scott
shindli
Eitan Isaacson
Emilio Cobos Álvarez
Agi Sferro
Matthew Gaudet
Daisuke Akatsuka
Ted Campbell
Dragana Damjanovic
Lina Cambridge
Punam Dahiya
John Lin
Tyson Smith
Mike Hommey
Gavin Lazar Suntop
Jan Henning
Randall E. Barker
Hiroyuki Ikezoe
Subhamoy Sengupta
Razvan Maries
Mike Shal
Jeff Walden
Jim Blandy
Bogdan Tara
Yury Delendik
Harry Twyford
Nazım Can Altınova
Morgan Reschenberg
David Parks
Divya Rani
Tom Schuster