We now set EventRegionsOverride flags on ref layers only, so
there's no need to have the APIs to set it on container layers in
general.
MozReview-Commit-ID: EX57VvaZv8A
--HG--
extra : rebase_source : 7ea4c8bb2716821bf7069158fdf9729fb6137a35
As with the previous patch, instead of setting the override on the root
layer, we set the flag on the nsDisplayListBuilder before building the
display list, and the flag automatically forces all event regions
display items to use their dispatch-to-content region instead of any
other regions.
Both the WebRender and non-WebRender codepaths were setting the override
flag on their root layers and don't need to any more.
MozReview-Commit-ID: KQV3w2nvlgs
--HG--
extra : rebase_source : 5be30af2d928117519296ec238eac91139986531
The mechanics of this change is fairly straightforward - instead of setting the
override on the layer corresponding to the in-process subdocument, we just set
the flag on the display list builder; that flag is already checked when building
the layer event regions for descendant nsIFrames.
As a side-effect, we also don't need to force a layer for in-process subdocuments
just because they have document-level APZ-aware listeners. One of reasons we were
doing so before was so that we would have a layer to stash the override flags on
but now we don't need that any more.
Note that out-of-process subdocuments are not affected; for those cases
the nsSubDocumentFrame delegates BuildDisplayList to
RenderFrameParent/nsDisplayRemote, which will still set the overrides on
the RefLayer that is created.
MozReview-Commit-ID: GTy9BmVVZ9q
--HG--
extra : rebase_source : be321091d6b5fe4b66738f2deeffbcfa6af0b521
This case is hit by hovering over menu items, so the optimization is somewhat worthwhile.
As a side-effect, not causing reflows also avoids a XUL <select> popup positioning bug.
MozReview-Commit-ID: AOrijytoHHL
--HG--
extra : rebase_source : c2156eb24171f6d0b0e5476c4a7dbc641a0b5301
InsertFirstLineFrames has been dead for a long time, and I don't think it's
worth to keep it around. It's in the VCS history anyway.
MozReview-Commit-ID: FetYB6nf38D
--HG--
extra : rebase_source : bc56cdec7a4e45c7ea1d8cf6354a5a6dc349ac29
As part of this change, the confusingly named global variable 'state' is
renamed to 'currentURLTargetType', and named "enum" values are assigned
to it rather than raw integers.
MozReview-Commit-ID: FTEOB9wF8Q1
If the reftest harness times out the load of a URL before the 'load' event
has even fired then the error message that we get is 'load failed with unknown
reason'. This isn't very helpful for people unfamiliar with the harness. This
change sets an initial error message that notes that we're waiting on the
'load' event, what the timeout delay is, and what URL we are/were waiting on
loading. This will allow the timeout delay to be compared to log timestamps
and will make it clear whether the timeout occurred for some other URL than
the one we were expecting to load (which would be an error in the harness
logic).
It should now be impossible for the 'load failed with unknown reason' to occur,
but if there is a logic error in the harness code (some race condition?) then
it may still happen.
MozReview-Commit-ID: JOb1kYBpLro
This makes it a bit more straight-forward to change the system font scale,
preserving the sync MediaFeatureChanged event.
This also avoids notifying media queries when the shell is not initialized.
In particular, the patch in bug 1404545 allows calling MediaFeatureValuesChanged
on a still-initializing pres-shell. This is nasty, and all this initialization
order is kind of a mess, but I'm not reworking it for now...
Also, this drops the invalidation of font-inflation when a doctype is added to
the document. GetViewportInfo() already relies on the doctype not changing, as
noted in a comment.
MozReview-Commit-ID: Knw7dM1B04Y