We already keep a cached version of the up-to-date value in nsPresContext,
there's no need to go through nsDeviceContext at all.
I don't expect this to fix bug 1424968 entirely, but it should make it a bit
better.
Differential Revision: https://phabricator.services.mozilla.com/D11639
--HG--
extra : moz-landing-system : lando
This is enough to fix the devtools regression and matches what other browsers
do in the no-attribute case.
Also, I think this change over all makes sense: it doesn't make any sense to
display the broken image icon if there's no request, and we already assume in
EnsureIntrinsicSizeAndRatio() that we don't paint the icon for those (and make
the intrinsic size 0x0).
We still show the border, which matches other UAs (note that devtools
effectively masks the border away with mask-image).
This technically also can change behavior of <object> and <input>, but I think
it's better to be consistent, since EnsureIntrinsicSizeAndRatio also doesn't
special-case <img> either.
Differential Revision: https://phabricator.services.mozilla.com/D11659
--HG--
extra : moz-landing-system : lando
Badly-behaved consumers of DrawTargetRecording can trigger recording of
draw calls that will fail to allocate required draw targets when the
recording is replayed. This patch tries to guard against this by
detecting these situations at record-time rather than crashing at
replay-time. When such a situation is detected, it will crash (for
content processes, to catch such scenarios) or gracefully fail (for
other processes).
Differential Revision: https://phabricator.services.mozilla.com/D11527
--HG--
extra : moz-landing-system : lando
This change eliminates
- nsLayoutUtils::LastContinuationOrIBSplitSibling calls for each CSS
properties on WebRender
- iterating over each display item for each compositor runnable CSS properties
- a bunch of stuff in the case where the layer manager has not yet created,
i.e. the compositor thread is not ready to receive animations
Depends on D11425
Differential Revision: https://phabricator.services.mozilla.com/D11426
--HG--
extra : moz-landing-system : lando
This change gets all effective CSS properties on an nsIFrame just once.
Note that LayerAnimationInfo::GetCSSPropertiesFor intentionally returns
nsCSSPropertyIDSet instead of nsCSSPropertyID since when we support individual
transform properties for the compositor the mapping between display item types
and nsCSSProperty has to be 1:N. E.g. all scale/translate/rotate properties are
mapped to transform display item.
Depends on D11424
Differential Revision: https://phabricator.services.mozilla.com/D11425
--HG--
extra : moz-landing-system : lando
Rotate accepts rotate axis and angle in any order
(i.e. <number>{3} <angle> or <angle> <number>{3}), so we rewrite the
parser.
Depends on D11401
Differential Revision: https://phabricator.services.mozilla.com/D11417
--HG--
extra : moz-landing-system : lando
LocalStorage needs to be exposed in every context except for sandboxes and
NullPrincipals (data: URLs, for instance). But we need to keep data
separate in some scenarios: private-browsing and trackers.
In private-browsing, LocalStorage keeps data in memory, and it shares
StorageEvents just with other origins in the same private-browsing
environment.
For Trackers, we expose a partitioned LocalStorage, which doesn't share
data with other contexts, and it's just in memory. Partitioned localStorage
is available only for trackers listed in the
privacy.restrict3rdpartystorage.partitionedHosts pref. See
nsContentUtils::IsURIInPrefList to know the syntax for the pref value.
Also, remove the unused NS_BLOCK_MARGIN_ROOT flag set on nsColumnSetFrame.
Differential Revision: https://phabricator.services.mozilla.com/D8783
--HG--
extra : moz-landing-system : lando
Basically, we rewrite the type of generics::transform::Translate and its
ToCss to match the spec. Besides, we always serialize Translate by servo,
so we could drop a lot of duplicated code.
Differential Revision: https://phabricator.services.mozilla.com/D11206
--HG--
extra : moz-landing-system : lando
It's only used in contenteditable.css, and same usage in comm-central. That
sheet is loaded as a ua sheet so let's restrict it to that. No relevant
external usage either. This value was introduced in bug 1181130.
Differential Revision: https://phabricator.services.mozilla.com/D11584
It's an attempt of an alias to `all`, except it doesn't get handled in all
places.
Seems unused both in comm-central and mozilla-central, and all external usage I
could find is followed by -webkit-user-select: all.
Differential Revision: https://phabricator.services.mozilla.com/D11582
This is the first step to unprefix user-select.
This has no behavior change, it's just a nicer way to do the same thing which
allows us to unship individual values more easily using parse(condition).
Differential Revision: https://phabricator.services.mozilla.com/D11580
It's only used in contenteditable.css, and same usage in comm-central. That
sheet is loaded as a ua sheet so let's restrict it to that. No relevant
external usage either. This value was introduced in bug 1181130.
Differential Revision: https://phabricator.services.mozilla.com/D11584
It's an attempt of an alias to `all`, except it doesn't get handled in all
places.
Seems unused both in comm-central and mozilla-central, and all external usage I
could find is followed by -webkit-user-select: all.
Differential Revision: https://phabricator.services.mozilla.com/D11582
This is the first step to unprefix user-select.
This has no behavior change, it's just a nicer way to do the same thing which
allows us to unship individual values more easily using parse(condition).
Differential Revision: https://phabricator.services.mozilla.com/D11580
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
Keep our old 'progressbar' as an alias for now, but unship
'progresschunk' by restricting it to UA/chrome sheets only.
Unship 'progresschunk-vertical' by removing it since it's
not used internally for anything.
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
--HG--
extra : source : 803b224d52a0940b4fb4b3b9cffc6a1fa6e5d4ee
Behavior-wise this only removes the HasAttr(src) check, and adds the IsEmpty()
check to the alt attribute value, since this function is only called for <img>
and <input>.
But it also cleans up a bit.
Differential Revision: https://phabricator.services.mozilla.com/D11194
The major change in this patch is ::-moz-column-span-wrapper blocks are no
longer linked into the continuation chains when they're created in
CreateColumnSpanSiblings(). We can do that because
::-moz-column-span-wrapper is an non-inheriting anon box, which doesn't need
to be restyled.
This prevents RestyleManager::ProcessPostTraversal or
nsIFrame::UpdateStyleOfOwnedChildFrame, which set the same style on all
continuations of the frame they are working with, from overriding the
::-moz-column-span-wrapper style.
GetNextContinuationWithSameStyle was deleted in bug 1447367. Delete the comment
in nsInlineFrame::UpdateStyleOfOwnedAnonBoxesForIBSplit() to avoid confusion.
This patch also adds another condition to reframe the multi-column container
in MaybeRecreateContainerForFrameRemoval(). That condition is when an
element has a "column-span:all" descendant, i.e. the element's frame has
"column-span:all" siblings (which is created by CreateColumnSpanSiblings).
The added test multicol-span-all-dynamic-remove-006.html will fail without
this patch.
Depends on D5212
Differential Revision: https://phabricator.services.mozilla.com/D9988
--HG--
extra : moz-landing-system : lando
Other frames calling InitAndWrapInColumnSetFrameIfNeeded() needs to be
modified to support column-span (bug 1489295).
Depends on D5208
Differential Revision: https://phabricator.services.mozilla.com/D5209
--HG--
extra : moz-landing-system : lando
This patch doesn't change behavior; it's just making some custom cleanup
code unnecessary by using a better fitting container class.
Differential Revision: https://phabricator.services.mozilla.com/D11237
--HG--
extra : moz-landing-system : lando
In this case aAncestor is an SVGOuterSVGFrame, and aItem is a transform item for
its AnonChildFrame.
I'm not sure if it's quite expected to have such a frame generating a
transform...
Let me know if not and I can try to dig more, but this looks intentional given
the comment in nsSVGOuterSVGAnonChildFrame.
Differential Revision: https://phabricator.services.mozilla.com/D10955
--HG--
extra : moz-landing-system : lando
This patch re-enables the new behavior of bug 1479964, to set keyCode or
charCode of keypress event whose value is zero to the other's non-zero value.
However, some web apps are still broken with the new behavior. Therefore,
this patch adds a blacklist to keep using our legacy behavior in some specific
web apps.
Note that Google Docs, Gmail and Remember The Milk are reported as broken.
However, I don't see any broken shortcut with Gmail. Therefore, this patch
adds only Google Docs and Remeber The Milk into the blacklist.
Differential Revision: https://phabricator.services.mozilla.com/D10322
--HG--
extra : moz-landing-system : lando
This gets rid of an unnecessary allocation.
Differential Revision: https://phabricator.services.mozilla.com/D11066
--HG--
extra : rebase_source : 138c808d78e666e55242bf142269d77fb065d7a6
extra : histedit_source : de8f5f4566cb886e155bce1a22e36f40af7b26f7
This commit removes all destruction code for RenderFrameParent to be handled by
TabParent. It's important that we remove the layer mapping in ActorDestroy to
prevent a race condition where the TabChild isn't fully destroyed yet and
sends a LayerTransaction constructor to the compositor and hits an
assertion.
Differential Revision: https://phabricator.services.mozilla.com/D11062
--HG--
extra : rebase_source : 61df2cfa3867617c39805883c06649624fffa518
extra : histedit_source : a810303ec335b4ab064dbd56b4652ea4c66deaad
This commit removes the PRenderFrame protocol, while keeping the same ordering
and semantics of graphics IPC initialization.
To do this, some messages are added to PBrowser to simulate the constructor
and destructor of PRenderFrame. Messages that expected a nullable PRenderFrame
are updated to get a boolean instead.
One tricky area is the destruction of PRenderFrame. I've tried to keep it the
same as much as possible, but it's possible it might be slightly semantically
different than IPDL destruction. Destruction will be touched up in a later
patch, so I'm not too concerned.
Differential Revision: https://phabricator.services.mozilla.com/D11057
--HG--
extra : rebase_source : bb8a7896bb4aefb6e9957d8808b755fa76cc00ed
extra : histedit_source : 6377819a946b5b6bc18b15f748229360e42a6f3a
The current spec says: "If only the X value is given, the Y value
defaults to the same value.", so we should update the behavior.
Besides, we also update the serialization, so we serialization both
specified and computed value by servo. We enable the preference
for all the css-transforms, so some of them are passed now.
Differential Revision: https://phabricator.services.mozilla.com/D10638
--HG--
extra : moz-landing-system : lando
Intermittently, at least on Windows, reftest.jsm finds that the reftest.xul
window is not focused on startup; focus seems to be on the dummy about:blank
window. This patch tries to detect that condition and correct it by bringing
reftest.xul (g.containingWindow) into focus before specifically focusing
the browser element (g.browser).
If mIsRunningOnCompositor is true, the property is effective state because
CanThrottle() is called in advance of a restyle for the effect so that we can
drop the check and drop skipping in the case of non-effective properties.
Depends on D10694
Differential Revision: https://phabricator.services.mozilla.com/D10695
--HG--
extra : moz-landing-system : lando
In the case of WebRender there is no layers, but actually we'd been using it for
WebRender too, that's confusing.
Depends on D10689
Differential Revision: https://phabricator.services.mozilla.com/D10690
--HG--
extra : moz-landing-system : lando