After introducing column-span, the ColumnSetWrapperFrame can have more
than one ColumnSetFrame children if there's any column-span:all child.
Thus we cannot use "height:100%" to pass block size information down to
the -moz-column-content's children.
Skip column span wrapper in nsIFrame::IsBlockWrapper() so that the
percentage column-span:all works.
Before this patch, the height of column contents are set to 100% of the
multicol container, so if the previous in-flows of column content
anonymous boxes consume all the height, later in-flows's height are all
0. In this patch, we don't restrict column-content's height, so their
height are calculated based on their children's height.
column-contain-1a.html passes because it can now correctly calculate the
union of all the column content's rect to find the correct sticky
positioning.
Differential Revision: https://phabricator.services.mozilla.com/D27627
--HG--
extra : moz-landing-system : lando
We remove initial x/y offset for nsSVGUtils::GetTransformMatrixInUserSpace
so that it can be used in not-nondisplay context. Previously it was only
used in nondisplay context, where x/y offset is always 0.
Then we use this utility to get the transform matrix to judge whether we need
special care for non-scaling-stroke. The old matrix doesn't account for CSS
transform.
Differential Revision: https://phabricator.services.mozilla.com/D28193
--HG--
extra : moz-landing-system : lando
In certain straight-forward cases where we detect a credit card number being used with password fields we will show a dismissed password manager doorhanger. The user can still choose to save in case the valid credit card number is actually their username or password.
1) If the Luhn checksum matches on the username field (see CreditCard.jsm) AND the password is 3 numerical digits (don't handle 4 for now even though it's used by Visa since there are banks that use 4 digits passwords for online banking still).
2) If the Luhn checksum matches on the password value AND we detect that the type=password field is a credit card field via autocomplete=cc-number.
** We must include the @autocomplete check otherwise sites will abuse this loophole on legit login forms and set autocomplete=cc-number on their password fields to avoid saving.
For both of these cases we should `dismissed:true` doorhanger, rather than not showing one at all, in case there are false-negatives.
Differential Revision: https://phabricator.services.mozilla.com/D25485
--HG--
extra : source : e9be442c871e173a409f3b969f5bcea0e1ae4d71
extra : histedit_source : c942a81512be954abe595fa41ca44c26cd89b0e6
In certain straight-forward cases where we detect a credit card number being used with password fields we will show a dismissed password manager doorhanger. The user can still choose to save in case the valid credit card number is actually their username or password.
1) If the Luhn checksum matches on the username field (see CreditCard.jsm) AND the password is 3 numerical digits (don't handle 4 for now even though it's used by Visa since there are banks that use 4 digits passwords for online banking still).
2) If the Luhn checksum matches on the password value AND we detect that the type=password field is a credit card field via autocomplete=cc-number.
** We must include the @autocomplete check otherwise sites will abuse this loophole on legit login forms and set autocomplete=cc-number on their password fields to avoid saving.
For both of these cases we should `dismissed:true` doorhanger, rather than not showing one at all, in case there are false-negatives.
Differential Revision: https://phabricator.services.mozilla.com/D25485
--HG--
extra : transplant_source : %A9%94_%9A%03%00%A1u%F3%28%C6%00H%16z%8A%8F%D6%18O
The reason why this fixes it is a bit subtle, let me try to explain.
XBL has this mechanism where all attributes in the binding `<content>` element
get auto-propagated to the bound element (the `<panel>` in this case).
This doesn't seem to be a very used feature looking at:
https://searchfox.org/mozilla-central/search?q=%3Ccontent&case=false®exp=false&path=xml
The panel binding uses it to add the `side` attribute:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/toolkit/content/widgets/popup.xml#264
The key here is that this attribute addition is silent (`aNotify=false`):
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/dom/xbl/nsXBLBinding.cpp#341
This means that the presence of this attribute is not supposed to change the
rendering of the page. It'd also be unsafe to notify at the point at which we
create XBL bindings.
So the way this happens is:
* We compute the initial style of the `<panel>` element (which doesn't have a
`side` attribute, and thus doesn't match the rules, and has a computed
opacity of 1).
* The XBL service _silently_ sets the `side` attribute. This should cause a
style change, but it doesn't since it's silent, so we remain with the
opacity of 1.
* We open the popup, and the XBL binding listens for the `popupshowing` event
and adds the `animate` attribute. The style system notices, and eventually
we compute the new style. Issue is, it has again an opacity of 1, so we
don't fire the transition.
Same with transform and such of course.
So far so good, but then, why does it work if there's a `<resources>` element
with an empty stylesheet? Fun that you ask!
We explicitly re-resolve the style of the element if there are any stylesheets:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/dom/xbl/nsXBLService.cpp#551
And thus grab the correct initial opacity of zero, and trigger the transition.
Given arrow panels always have a `side` attribute (and same for the bookmarks
thing), making their style not depend on the silent attribute additions from
`<content>` fixes the bug.
We could fix the bug with an alternative patch (re-resolving style if there's a
`<content>` element with attributes in the binding). This wouldn't be completely
sound anyway in presence of combinators, and given that it'd remain being
unsound anyway, we should probably just remove that feature.
Also, the simplification of the stylesheets seems worth it anyway.
I'll follow-up removing the `<resources>` implementation, and we should probably
investigate removing the `<content>` attribute propagation, since it's the
really unsound thing here.
Differential Revision: https://phabricator.services.mozilla.com/D28310
--HG--
extra : moz-landing-system : lando
The imported version is just one commit over 0.2.2 and solves the crash for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D28343
--HG--
extra : moz-landing-system : lando
We want to drop the cascade data memory as soon as possible, so bug 1544546
introduced an UpdateStylistIfNeeded call from ShellDetachedFromDocument.
Unfortunately, this call can reenter into the global user-agent cascade data if
some of the CSS values kept alive by the cascade data keep alive an SVG
document, see the stack on this bug for an example. Make sure to drop the
user-agent cascade datas when not holding the cache lock to avoid this
situation.
Before bug 1535788, we just destroyed the stylist, so we kept holding a
reference from the cache, and that reference will be dropped sometime later when
other document updated their user-agent stylesheets (if they happened not to
match the cache of course).
Seems to me this doesn't ended up happening in our automation, but it could
happen in the wild, in theory at least.
It's nice that Rust made this a safe deadlock caught by our tests rather than a
very subtle and infrequent memory corruption.
The relevant SVG documents are probably the <input type=number> rules:
https://searchfox.org/mozilla-central/rev/d80f0a570736dce76a2eb184fb65517462089e8a/layout/style/res/forms.css#1050
Differential Revision: https://phabricator.services.mozilla.com/D28299
--HG--
extra : moz-landing-system : lando
Turns out these suites were hardcoded to be non-e10s in the mochitest harness.
So while it looked like they were working with e10s in treeherder, they were
actually still running with it disabled.
Turning e10s on causes both suites to permafail due to timeouts.
Depends on D28386
Differential Revision: https://phabricator.services.mozilla.com/D28387
--HG--
extra : moz-landing-system : lando
This was regressed by bug 1544816 but the test never ran on the push that regressed.
This patch also updates the 'files-changed' for the tryselect task.
Differential Revision: https://phabricator.services.mozilla.com/D28386
--HG--
extra : moz-landing-system : lando
This override has no effect in CoreAnimation-backed windows. The upcoming
patches will implement an alternative approach.
Differential Revision: https://phabricator.services.mozilla.com/D22644
--HG--
extra : moz-landing-system : lando
The synchronous paint was only needed a long time ago when we were calling this
method during drawRect. We're not doing that any more, we usually call it from
viewWillDraw now. But even at the time, forcing a synchronous paint *within*
a paint was extremely sketchy, so best just to remove the code.
Differential Revision: https://phabricator.services.mozilla.com/D22642
--HG--
extra : moz-landing-system : lando
FxR uses these prefs and they might be helpful to other embedders so we can
just add them to GeckoRuntimeSettings.
Differential Revision: https://phabricator.services.mozilla.com/D28232
--HG--
extra : moz-landing-system : lando
Robert Helmer
Brindusan Cristian
Ting-Yu Lin
Jeff Gilbert
violet
prathiksha
Matthew Noorenberghe
longsonr
Michael Kaply
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Alexander Surkov
Oana Pop Rus
Gurzau Raul
Ed Lee
Alex Chronopoulos
Daosheng Mu
Andrew Erickson
Avery Berninger
Grisha Kruglov
Bogdan Tara
Andrew Halberstadt
Miko Mynttinen
Jason Laster
Markus Stange
Aaron Klotz
Agi Sferro