This patch:
* Makes LengthPercentageOrAuto generic, and removes a bunch of code fo
LengthPercentageOrNone, which was used only for servo and now can use the
normal MaxLength (with a cfg() guard for the ExtremumLength variant).
* Shrinks MaxLength / MozLength's repr(C) reperesentation by reducing enum
nesting. The shrinking is in preparation for using them from C++ too, though
that'd be a different bug.
* Moves NonNegative usage to the proper places so that stuff for them can be
derived.
I did this on top of bug 1523071 to prove both that it could be possible and
that stuff wasn't too messy. It got a bit messy, but just because of a bug I
had fixed in bindgen long time ago already, so this updates bindgen's patch
version to grab a fix instead of ugly workarounds :)
Differential Revision: https://phabricator.services.mozilla.com/D17762
Also for the intersection observer root margin, since it was easier to fix it
up and clean it up than not doing it.
This is the first big step to get rid of nscoord. It duplicates a bit of logic
in nsLayoutUtils since for now max/min-width/height are still represented with
nsStyleCoord, but I think I prefer to land this incrementally.
I didn't add helpers for the physical accessors of the style rect sides that
nsStyleSides has (top/bottom/left/right) since I think we generally should
encourage the logical versions, but let me know if you want me to do that.
Differential Revision: https://phabricator.services.mozilla.com/D17739
PresShell::EventHandler::ComputeRootFrameToHandleEvent() computes root frame
to handle event with popup frame and/or capturing content. The former result
can be rewritten with the latter. So, for cleaning it up with early return
style, we need to split it to 2 methods.
Differential Revision: https://phabricator.services.mozilla.com/D18525
--HG--
extra : moz-landing-system : lando
remove line-height:normal rule from html.css for <sub> and <sup> for interop.
Differential Revision: https://phabricator.services.mozilla.com/D18636
--HG--
extra : moz-landing-system : lando
In some reasons, handling event should be handled in specific frame even if
the coordinates are out of the frame. PresShell::EventHandler::HandleEvent()
computes it with popups, capturing content, etc. This patch moves the blocks
into new method for making HandleEvent() simpler.
Note that most of the code is just moved. The following patch will clean it
up.
Differential Revision: https://phabricator.services.mozilla.com/D18523
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() tries to flush pending animation first
when it decides frame to handle events using coordinates. This patch moves
the code into the new method.
Differential Revision: https://phabricator.services.mozilla.com/D18522
--HG--
extra : moz-landing-system : lando
Summary:
Editor changes caret visibility during drag and drop. But when destroying
editor, we don't restore caret state. So we should restore it when destroying
editor.
Tags: #secure-revision
Bug #: 1496118
Differential Revision: https://phabricator.services.mozilla.com/D18923
--HG--
extra : rebase_source : 157f2c9e69857c7f7adb916af2a319392c4d125a
There is an unclear variable `frame` in PresShell::EventHandler::HandleEvent().
It's overwritten with different frame and its meanings is changed sometimes.
Finally, it's necessary only in the `if (aGUIEvent->IsUsingCoordinates())`
block. Therefore, we can move it into the block and rename it when them for
each purpose.
Differential Revision: https://phabricator.services.mozilla.com/D18521
--HG--
extra : moz-landing-system : lando
Both of reftests in this commit are based on an exmaple [1] in the Viewports
Explainer written by David Bokan.
position-fixed-out-of-view.html fails without the fix because the position:fixed
element is rendered at the right edge of the visual viewport so that it's
visible in the first place.
position-fixed-on-minimum-scale-size.html does NOT fail without the fix either
because the position:fixed element sticks at the right edge of the visual
viewport so that it still be there even after the visual viewport offset has
been changed.
[1] https://github.com/bokand/bokand.github.io/blob/master/web_viewports_explainer.md#chrome-2
Differential Revision: https://phabricator.services.mozilla.com/D18797
--HG--
extra : moz-landing-system : lando
Copy fonts loaded during a mozPrintCallback into the cloned document,
so they are available during printing.
Differential Revision: https://phabricator.services.mozilla.com/D18613
--HG--
extra : moz-landing-system : lando
PresShell::EventHandler::HandleEvent() discards or puts off to dispatch
the handling event if it's a keyboard event and event dispatching is
suppressed by the document.
This patch moves the block into the new method for making HandleEvent() simpler.
Differential Revision: https://phabricator.services.mozilla.com/D18520
--HG--
extra : moz-landing-system : lando
This commit removes the dependency on RenderFrame from nsDisplayRemote so that
it can work in child processes with remote subframes. Instead nsDisplayRemote
now works with an nsFrameLoader, which will return the LayerId from either
the RenderFrame (for top-level remote browsers), or from RemoteFrameChild
(for remote subframes).
Differential Revision: https://phabricator.services.mozilla.com/D17448
--HG--
extra : rebase_source : 94d05ddbe5943be09c0446cf218074596bc85000
extra : source : 1e1b5cd23412a85fad19ab8ec5aacf31b3a9c9b6
A TabParent for a remote subframe will have the same owner content as the top-level
remote browser. This means that 'TabParent::GetFrameLoader()' will return the
frame loader of the top-level remote browser.
This is fine for getting the layer manager and compositor for connecting layer trees,
but the frame loader is also used to acquire a TabParent for its process ID. This
is incorrect in the remote subframe case, and will lead to the compositor rejecting
layer transactions for the remote subframe because it will only accept them from
the top-level remote browser's process.
This commit switches RenderFrame to just hold on to TabParent, and acquire the
nsFrameLoader as necessary.
Another change is to RenderFrame::SetOwnerContent. Previously this method would
take the new owner content and check an assertion. I don't see much value in the
assertion, so I've removed it. Additionally, now that we acquire the owner content,
and therefore the layer manager, from TabParent, we need to ensure that
RenderFrame::SetOwnerContent is ran after the TabParent has had it's owner content
updated. So the callsite has been moved into TabParent. This resolved a test failure
with frame loader swapping.
Differential Revision: https://phabricator.services.mozilla.com/D17447
--HG--
extra : rebase_source : dfda7cc49d057e0e72b4a4e84d124872493d8761
extra : source : 4c85fb68f2ed297828bf4646301c2d80d1c8e0a1
The documentation for these pieces are a bit out of date.
Differential Revision: https://phabricator.services.mozilla.com/D17446
--HG--
extra : rebase_source : ae465b1373f97c669bbc012dd1b152a9838d8c98
extra : source : ba62cc27c32f4d8a3fefff8eee5bf47d270130bc
For cases where the class has direct calls (that is, we cast `this` to the
subclass before making the call) no longer declare Recv/Answer methods on the
base class at all. This should ensure that slots for them are not generated in
vtables, and also allow the derived class to choose the method signature (e.g.
whether it wants to take something by reference or by value).
Differential Revision: https://phabricator.services.mozilla.com/D18132
--HG--
extra : moz-landing-system : lando
When calling a Recv/Alloc/Dealloc method on most types, cast `this` to the
derived class.
There is a heuristic to figure out what the correct derived type is. There is a
blacklist of types which we can't do direct calls on for the moment, as well as
an override for types that do work with direct calls but which don't match the
heuristic.
Differential Revision: https://phabricator.services.mozilla.com/D16492
--HG--
extra : moz-landing-system : lando
Before this patch, we made scrollable frames derive their baseline from their
margin-box, because that's what the spec requires for scrollable inline-block
boxes. However, the spec now singles out inline-block as a special case, and
other sorts of scrollable inline-level containers are supposed to derive their
baseline from the scrolled content. So, this patch makes us do that, with an
exception for scrollable inline-block boxes.
For more info about the block-inside special case, see the end of the "block
containers" chunk here: https://drafts.csswg.org/css-align/#baseline-export
(Though that spec text may be a bit too specific, per my spec issue at
https://github.com/w3c/csswg-drafts/issues/3611 -- that's why this patch checks
for block-inside rather than inline-block.)
Differential Revision: https://phabricator.services.mozilla.com/D18481
--HG--
extra : moz-landing-system : lando
