In our current setup, in which links with an href attribute always match either
:link or :visited, no matter whether that attribute's value is a valid URI,
changes to the attribute always put the element into either the "match nothing"
state or the "match :link" state, via calls to Link::ResetLinkState.
The only thing FlushPendingLinkUpdates is needed for is (lazily, in case it
turns out to not be needed because the element got removed from the DOM anyway)
registering a history observer to switch the link state to :visited as needed.
This means that selector matching consumers that would never expose :visited
state to start with don't need to worry about calling FlushPendingLinkUpdates.
The only remaining callers of RelativeToParent() are in
StackingContextHelper itself, which we can remove now by having the SCH
take a parent SCH and use it instead of RelativeToParent(). This patch
implements this change.
This makes a failing test pass, because of how preserve-3d container
layers work. Specifically, preserve-3d container layers render their
descendants in z-order, not in tree order. If those children were assuming
that their parent had already pushed a stacking context, that assumption
may have been false because the parent might have not yet been rendered
because of z-ordering. By using the StackingContextHelper chain instead
of the layer tree ancestry, we fix the stacking-context-relative coordinates
being used in the descendant subtree of preserve-3d container layers.
MozReview-Commit-ID: HzZvBuAlMdB
This updates more code that was using RelativeToParent() to use the
stacking context helper's ToRelativeWr* functions instead. This get us
closer to breaking the assumption that the WR stacking context order maps
1:1 to the layer tree structure.
MozReview-Commit-ID: HQrbvCgPOW4
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This uses the StackingContextHelper and typed helper functions in
WebRenderLayer to simplify WebRenderTextLayer::RenderLayer. It also
removes the implicit assumption in WebRenderTextLayer that the parent
layer pushed a stacking context, which is an assumption we will
probably break in the future.
MozReview-Commit-ID: CARoGVQd56i
This is needed for the next patch, because the bullet frame WR rendering
code will need a StackingContextHelper to pass to the PushGlyphs call.
It also helps with some of the later patches in this series, when we get
rid of the RelativeToParent calls.
MozReview-Commit-ID: Is0aciHhy2N
Non-ascii characters in error messages can cause exceptions when processing
structured log messages. The mochitest MessageLogger already handles such
cases; this is a simpler implementation for the reftest OutputHandler.
scrollbars.css is the only sheet which is parsed as author level, but later
added as agent level in [1]. Add a new enum value so that it can be parsed
as author level in gecko (nsCSSParser::AgentRulesEnabled() will exclude it),
but servo can recognize it as agent level sheet when the sheet is created.
Delete UserRulesEnabled() because no one uses it.
[1] http://searchfox.org/mozilla-central/rev/7419b368156a6efa24777b21b0e5706be89a9c2f/layout/base/nsDocumentViewer.cpp#2326
MozReview-Commit-ID: 2lrV4ogfnHM
--HG--
extra : rebase_source : 02ff7bf64520ec3de5647059f18989a7971a8a5d
This also adds assertions to ensure attributes and state don't change during
layout or frame construction.
MozReview-Commit-ID: BANcpxnRsYS
--HG--
extra : rebase_source : 5d1bc424d3ed90fda3047d3c92c09251346b7bec
This patch do following things:
1. Create nsDisplayTableBorderCollapse that draws all collapse border of
table.
2. Don't use nsDisplayTableBorderBackground.
3. Let column and column group frame generate display items.
4. When traversing the table, also traverse the column and column group
frames.
5. For each type of table frame (col group, col, row group, row and
cell), draw their own background.
MozReview-Commit-ID: 1s2VLv6G8xi
Currently the profiler mostly uses an array of strings to represent which
features are available and in use. This patch changes the profiler core to use
a uint32_t bitfield, which is a much simpler and faster representation.
(nsProfiler and the profiler add-on still use the array of strings, alas.) The
new ProfilerFeature type defines the values in the bitfield.
One side-effect of this change is that profiler_feature_active() now can be
used to query all features. Previously it was just a subset.
Another side-effect is that profiler_get_available_features() no longer incorrectly
indicates support for Java and stack-walking when they aren't supported. (The
handling of task tracer support is unchanged, because the old code handled it
correctly.)
Fixed backgrounds were not being clipped correctly when rendered using
inactive layers.
MozReview-Commit-ID: 3v8tajr3MoB
--HG--
extra : rebase_source : 25329cb9efb998c64924916d4ea496a439688c8d
That function has a special path for when there's no parent reflow input, and if
there's a parent reflow input there should always be a parent frame.
MozReview-Commit-ID: EYh0aE4ozBg
By passing the startTime as a TimeDuration we are able to represent times in the
distant past (and with the same range as we can represent on the main thread so
that if we do encounter range errors in future, they should not differ between
the main thread and the compositor).
This patch includes a crashtest. I have verified that, without the code changes
included in this patch, this crashtest fails on debug builds on OSX.
MozReview-Commit-ID: EDuKLzfEC0K
--HG--
extra : rebase_source : 1883080fdfac8c33f70698145f21e67cbdfdd4f2
The origin of a tiled gradient needs to be positioned less than the origin
of its clip bounds, otherwise it won't fill all of its clip bounds. There
is an existing function used by the current code path that can be used to
do this.
MozReview-Commit-ID: 13EtwmZYT4P
--HG--
extra : amend_source : 4fbe6b72efc61b1ef8303422e6e0910970d49fa0
Written in a kind-of creative way, but I plan to upstream it to WPT, so this is
the best way I found to do it.
MozReview-Commit-ID: 3GBeZk3uq11
--HG--
extra : rebase_source : 2faf6091f46db09c819b8d9fa5920a35fa8661b7
This patch shouldn't affect behavior -- it just takes a latent opportunity for
simplification and removes an unused layer of indirection. These functions were
set up to look like they took outparams, but none of the callers were using the
value left in the outparam.
MozReview-Commit-ID: LaL7YiyVYS2
--HG--
extra : rebase_source : 28466d6ab36da2e3609e7ed0fdb51618e652c7f7
The call that's causing the crash seems to be [1], that is, we're trying to
recreate frames for the root element, which should always have a frame created
at the initialization of the PresShell.
So the function I removed in that bug had something like the following:
if (!mDidInitialize) {
// Nothing to do here. In fact, if we proceed and aContent is the
// root we will crash.
return NS_OK;
}
Which PostRecreateFramesFor doesn't guard against (because I thought it was not
needed, per tryserver results).
Sounds a lot like we do need that check, though I'd like to have a testcase
where it happens :(
[1]: http://searchfox.org/mozilla-central/rev/3dc6ceb42746ab40f1441e1e659ffb8f62ae78e3/layout/base/nsCSSFrameConstructor.cpp#2420
MozReview-Commit-ID: Lh6SohNmmI6
--HG--
extra : rebase_source : 5b7076f86d41f5489e47ca16ac2f3620812ee9e8
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
An IPCBlobInputStream can be sent back to the parent process (not implemented
in this patch). When this is done, we basically send only the internal ID.
From this ID, we can retrieve the original inputStream because any
IPCBlobInputStreamParent actor has previously registered it into a singleton:
IPCBlobInputStreamStorage.
So, if we have a IPCBlobInputStreamParent, we have an inputStream, and this
inputStream is known by IPCBlobInputStreamStorage. This will be useful in the
next patches.
The logic around here is a bit tricky, because -moz-linear-gradient() shares
this codepath. Here's how things were going wrong:
* The -moz-linear-gradient syntax allows an angle (e.g. "30deg") to be followed
by an optional box-position (e.g. "top right") before eventually requiring a
comma and then some color stops.
* In contrast, the -webkit-linear-gradient syntax does NOT allow a box-position
there (unless the box-position is by itself, without an angle).
* So, for -webkit-linear-gradient, we (correctly) skipped the box-position
parsing code, if we've seen an angle already.
* BUT: in skipping that code, we *also* inadvertantly skipped the code that
enforces that we eventually see a comma before we get to the color stops.
So, we incorrectly accept some -webkit-linear-gradient() expressions that are
missing a comma that really should be mandatory.
So, this patch adds a special case for -webkit-linear-gradient that
preemptively bails if we get an angle that's not followed by a comma. (With
that, we can also simplify the condition around the box position parsing, too.)
MozReview-Commit-ID: B7MQLxqe6D7
--HG--
extra : rebase_source : 0682884e68fbf51d50dc24b1a6a7656cc998ecb2
Supporting custom scrollbar mediators would require having custom logic in APZ
for each custom mediator. Since custom mediators are only used by legacy XUL
elements (<listbox> and <tree>) that isn't worth implementing.
MozReview-Commit-ID: KtCUvtiR1qn
--HG--
extra : rebase_source : dfd301da4d6877dd636c9719df46409db260d94c
nsIFilePicker.displaySpecialDirectory is a string that can be set to TmpD,
Desk, or any other special directory value. The real value of this directory
will be read in the parent process.
We want to see if we can drop support due to web pages not using it.
Edge and Safari already don't support it, and Chrome reports that usage
is low enough that they're willing to drop it. But telemetry doesn't
tell us about web usage if we're triggering it via our own internal
code.
MozReview-Commit-ID: 5YBfhQJExHC
--HG--
extra : rebase_source : fd359e3264ba96ef10617f4de767080c94b792fb
Per description in bug 1361072, this is the standard idiom to assign
outparam pointers of refcounted types.
MozReview-Commit-ID: 6kmDslMs94j
--HG--
extra : rebase_source : c151f0e6050cfd3ce1cf914eeb350166c539d160
Continue to allow non-multiprocessCompatible extensions in automation.
There are a ton of places that would need to be changed, many of which
will be changing soon anyway with the non-webextensions change in 57
so this is mostly the expedient route to keeping the tree green.
MozReview-Commit-ID: EZZoDVdhLfy
--HG--
extra : rebase_source : 34aa762917566b052ade6372280caed72fbfbe9a
Without this change, we can end up asserting in ComputeVariablesData and
crashing in CSSVariableResolver::Resolve due to not finding any variable
declarations on the rules we matched, when we have content like in the
crashtest added here, i.e. variables inheriting into a pseudo like
::first-line and animations on the element inside the ::first-line.
We could solve this alternatively by removing the assertion and making
CSSVariableResolver::Resolve handle a null aDeclarations more gracefully,
but since we can save the effort of recomputing the Variables struct in
this case, we may as well.
MozReview-Commit-ID: 6l06ZF3WGsy
Continue to allow non-multiprocessCompatible extensions in automation.
There are a ton of places that would need to be changed, many of which
will be changing soon anyway with the non-webextensions change in 57
so this is mostly the expedient route to keeping the tree green.
MozReview-Commit-ID: EZZoDVdhLfy
--HG--
extra : rebase_source : f83472bc1c88dd0deadbe485d9002499027ff07f
Currently, we only correctly support remote layer trees for frameloaders that
use the same layer manager as their document. Since we need to be able to host
remote <browser> content in popup widgets for remote WebExtensions, we need to
tie the frameloaders to the layer manager of their host element, rather than
the root layer manager for the document.
MozReview-Commit-ID: 4RCsamFBiQw
--HG--
extra : rebase_source : 86bca4ae1c012ff1bb84a9ad796be311cfe580f6
extra : histedit_source : 19577d69430adc8cb38c195f13db2c6de6605c4c
