This makes it so that apilints lints with "GV" codes are enforced and will fail
the build.
Depends on D13882
Differential Revision: https://phabricator.services.mozilla.com/D13883
--HG--
extra : moz-landing-system : lando
The argument has never been used since the function the function was introduced
in bug 240276.
Differential Revision: https://phabricator.services.mozilla.com/D14713
--HG--
extra : moz-landing-system : lando
This ended up not being so small of a patch as I'd have thought, since it
propagated a bit. But most of it is mechanical. Interesting part is
NonNegativeNumberOrPercentage and the actual uses of the NonNegative stuff and
during parsing.
This looks like it'd fix a few correctness issues during interpolation for all
the types except for BorderRadius and co (which handled it manually).
I should write tests for those in a different patch.
Depends on D14672
Differential Revision: https://phabricator.services.mozilla.com/D14673
--HG--
extra : moz-landing-system : lando
Summary:
The latest version of Gecko doesn't crash by this HTML, but I would like to add
this for the future.
Bug #: 1441619
Differential Revision: https://phabricator.services.mozilla.com/D14846
--HG--
extra : rebase_source : 5633e508d1c1f405465857a71f7c544fbb3782e8
Summary:
Add autofill hint test if using Android 8+.
Depends on D12881
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12882
--HG--
extra : rebase_source : c4458b62d48434fe9d19f8ded04f2bc2666647ff
extra : histedit_source : 5ff01309b49965ff008e431059368ca0f05d56e6
Summary:
LastPass will fill password to all input elements which InputType is
TYPE_CALSS_TEXT and TYPE_TEXT_VARIATION_WEB_EDIT_TEXT and has no AutofillHint.
And it will fill username when InputType and AutofillHint is nothing in
<input type="text">.
Actually, current implementation of GeckoView sets InputType only for
<input type="text">, so LastPass fills password to all <input type="text">
So as workaround, we should set InputType and AutofillHint when input element
presumes username fields.
Depends on D12880
Reviewers: droeh
Reviewed By: droeh
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12881
--HG--
extra : rebase_source : b5ab3deadf0dd67bbdb1aa7e7656fe677c6670c4
Add top-level and auxiliary browsing contexts to a group of
BrowsingContexts on creation and store a pointer to that group in all
children of the BrowsingContexts in the group. With this it is
possible to compute the transitive closure of related browsing
contexts.
Since we'll not be using linked lists of BrowsingContexts for neither
groups nor children we can move children to be an array of
BrowsingContexts and adjust to use a the more convenient HashMap for
roots.
Differential Revision: https://phabricator.services.mozilla.com/D13227
--HG--
extra : moz-landing-system : lando
The following APIs are changed.
1. Contains() needs to become contains(). (EnumSet's methods have lowercase names.)
2. Use list constructor rather than "|" like a plain enum.
3. Use operator+= instead of operator|=.
Differential Revision: https://phabricator.services.mozilla.com/D14908
--HG--
extra : moz-landing-system : lando
Summary:
I would like to get username fields etc from form or input element in form.
Since LoginManagerContent._getFormFields has "_" prefix (it means private
member) and LoginManagerCotnent.getFieldContext doesn't return elements,
I would like to add simple API for it.
Reviewers: MattN
Bug #: 1497682
Differential Revision: https://phabricator.services.mozilla.com/D12880
--HG--
rename : toolkit/components/passwordmgr/test/unit/test_getFormFields.js => toolkit/components/passwordmgr/test/unit/test_getUserNameAndPasswordFields.js
extra : rebase_source : b4a354231b85371144ccc0fff76f948ae0d09278
I'm about to introduce another use of it and I don't want to repeat the same
copy-pasta again.
Differential Revision: https://phabricator.services.mozilla.com/D14672
--HG--
extra : moz-landing-system : lando
This also makes it so that the initial browser tab setup code can handle a JS array
as the URI(s) to load during start-up. If it's an array, the first element of that
array is inspected to determine what process type the initial browser tab should
be in.
Differential Revision: https://phabricator.services.mozilla.com/D14755
--HG--
extra : moz-landing-system : lando
This test formerly used a bootstrapped extension. Converting it to a
webextension is straightforward, except for the fact that webextensions
are started asynchronously, so the test has to wait for a message from
the addon instead of just assuming it is started synchronously during
distribution handling.
Differential Revision: https://phabricator.services.mozilla.com/D13635
--HG--
extra : moz-landing-system : lando
The <iframe> in the test case is getting the "column-span:all" style,
but it's under a position:fixed frame subtree. After the patch in bug
1507244 landed, NS_FRAME_HAS_MULTI_COLUMN_ANCESTOR won't be added
incorrectly to the out-of-flow subtree.
Differential Revision: https://phabricator.services.mozilla.com/D14626
--HG--
extra : moz-landing-system : lando