This makes EXIF orientation metadata honored by default.
Introduce OrientedPixel and UnorientedPixel typed rects and sizes and
use them throughout RasterImage so that we don't confuse which we want.
The reason for doing this rather than having the imgLoader wrap every
RasterImage it creates with an OrientedImage is that returning the
wrapper messes with various notifications, as OrientedImage is not an
ImageResource.
(It would be even better if the JPEG decoder could decode to imgFrames
handling the EXIF orientation itself, but that's a more complicated
change.)
Differential Revision: https://phabricator.services.mozilla.com/D70273
--HG--
extra : moz-landing-system : lando
RasterImage will make use of them.
Note that there is one bug fix in this patch, which is that
OrientedImage::OrientSurface now creates a surface of the correct size.
(Previously this code was creating a surface with the underlying
image's size, rather than the correctly oriented size. But we must
not have been calling into that code with our current uses of
OrientedImage.)
Differential Revision: https://phabricator.services.mozilla.com/D70271
--HG--
extra : moz-landing-system : lando
We can modify the scroll position without invalidating the anchor (that's kind
of the point, actually).
So it's possible (and ok) to end up with a frame which is already maintaining
an anchor but for which CanMaintainAnchor now returns false.
So if you have a scrollframe with a non-zero scroll position and select an
anchor for that scrollframe, and then try to select an anchor for an ancestor,
you don't want to dig into there.
Differential Revision: https://phabricator.services.mozilla.com/D71103
--HG--
extra : moz-landing-system : lando
When an element with overflow:auto becomes scrollable, either by a style change or growing children, it should become focusable and fire a state change. Same in the inverse.
Differential Revision: https://phabricator.services.mozilla.com/D70561
--HG--
extra : moz-landing-system : lando
Changes to attributes such as disabled, contenteditable, and tabindex should cause FOCUSABLE
state changes to be fired when indeed the accessible gains or loses focusability.
Differential Revision: https://phabricator.services.mozilla.com/D70560
--HG--
extra : moz-landing-system : lando
For now, the local detection sucks. I will fix that once bug 1625884
is fixed
Differential Revision: https://phabricator.services.mozilla.com/D69683
--HG--
extra : moz-landing-system : lando
Move the TI heuristic into BCE::emitFunction where the other special mutation
of inner-functions is happening.
Differential Revision: https://phabricator.services.mozilla.com/D70781
--HG--
extra : moz-landing-system : lando
Instead rely on consistent definitions of the TreatAsRunOnce flag on the
SharedContext. Also simplify the BCE::check{RunOnce,Singleton}Context
accessors. Note that the TreatAsRunOnce flag indicates the script is expected
to run-once, but the BCE also checks for isInLoop to decide if current
bytecode location within the script should still be considered run-once.
Differential Revision: https://phabricator.services.mozilla.com/D70780
--HG--
extra : moz-landing-system : lando
Use the same conditions for qualifying an inner function as a run-once-lambda
between the lazy and non-lazy code paths. Use the FunctionBox::immutableFlags
so that this works well with delazification too.
Differential Revision: https://phabricator.services.mozilla.com/D70779
--HG--
extra : moz-landing-system : lando
In the BytecodeEmitter constructor, initialize the TreatAsRunOnce flag for
top-level SharedContexts. In the future we should initialize this even
earlier. For the delazification case, we initialize already directly
initialize this flag from the lazy BaseScript.
Differential Revision: https://phabricator.services.mozilla.com/D70778
--HG--
extra : moz-landing-system : lando
The interpreter calls `TierUpTick` whenever we interpret a regexp. Once we hit the tick threshold, compileIfNecessary will compile native code for the regexp.
Currently the tick threshold is hard-coded to 10. V8's tick threshold is 1, which seems unreasonably low. We can tune this later.
Differential Revision: https://phabricator.services.mozilla.com/D70952
--HG--
extra : moz-landing-system : lando
The current ForceByteCodeEnum is a glorified boolean. This patch replaces it with a three-value bytecode/jitcode/either enum, which will make our tiering-up logic slightly nicer in the next patch.
Differential Revision: https://phabricator.services.mozilla.com/D70951
--HG--
extra : moz-landing-system : lando
Internally, irregexp uses -1 for errors, 0 for failure, and 1 for success. We have to use the same values in RegExpRunStatus.
Ideally we would replace RegExpRunStatus with an enum defined in RegExpTypes.h, but that will have to wait until we get rid of the old import.
Differential Revision: https://phabricator.services.mozilla.com/D70728
--HG--
extra : moz-landing-system : lando
The irregexp compiler takes the AST produced by the parser, compiles it down to a more efficient internal representation, then uses a 'macroassembler' to generate code. The generated code can either be bytecode (which is then fed into the interpreter) or jitcode (which can be executed directly).
This patch gets the infrastructure set up and handles the former case.
CompilePattern is based heavily on V8's `RegExpImpl::compile` (affc364620/src/regexp/regexp.cc (L745-L933)). I am upstreaming a patch to move the code in WrapBody into regexp-compiler.cc where it fits better.
V8 is about to land a patch to tweak the API for Interpret so that it allocates memory for its registers internally instead of requiring it to be passed in. When we import this change, we'll be able to pass `matches->pairsRaw()` directly into `MatchForCallFromRuntime`, and the interpreter will fill it in for us.
In the old engine, we could handle interrupts in the middle of the interpreter. If we hit an urgent interrupt in compiled code, we would generate bytecode and fall back to the interpreter (see https://searchfox.org/mozilla-central/rev/9120151ddb35f2d4c37bfe613a54a4f10a9a3dc5/js/src/vm/RegExpObject.cpp#1165-1175). (This is what all the `ForceByteCode` machinery in RegExpObject.cpp is about. It was added in bug 1077514.) That won't work in the new version. V8 does allow interrupts during regexp execution, but only by jumping through some scary hoops to "manually relocate unhandlified references" afterwards. Instead, we just retry the regexp. I have no idea what a reasonable number of retries is before giving up; I've arbitrarily picked 4 for now.
Differential Revision: https://phabricator.services.mozilla.com/D70695
--HG--
extra : moz-landing-system : lando
In preparation for actually compiling regexps in the next patch, hook up the V8 and irregexp representations of a compiled regexp.
Differential Revision: https://phabricator.services.mozilla.com/D70694
--HG--
extra : moz-landing-system : lando
A regexp with N sets of capturing parens will have N+1 capture groups, with the extra capture containing the entire matching string. Our old implementation stored `parenCount` in the RegExpShared and then added 1 to it whenever it was used. A much simpler answer is to just add 1 when initializing the regexp.
Differential Revision: https://phabricator.services.mozilla.com/D70693
--HG--
extra : moz-landing-system : lando
I left all the bits that related to grid container, such as setting
aStatus, NS_STATE_GRID_DID_PUSH_ITEMS, and aState.mIter in
nsGridContainerFrame::ReflowRowsInFragmentainer().
Differential Revision: https://phabricator.services.mozilla.com/D68492
--HG--
extra : moz-landing-system : lando
We have duplicated ReparentFrame and ReparentFrames define in both
nsBlockFrame and nsGridContainerFrame. We should move them into
nsContainerFrame.
Differential Revision: https://phabricator.services.mozilla.com/D68490
--HG--
extra : moz-landing-system : lando
And batch them when notifying child processes.
This makes RegisterVisitedQuery potentially notify synchronously, but changes
the code to deal with it properly.
Differential Revision: https://phabricator.services.mozilla.com/D69187
--HG--
extra : moz-landing-system : lando
This patch just ensures the changes in the previous patches get applied
to the WR codepath, and is sufficient to make all the remaining sticky
tests pass on Android+WR.
Differential Revision: https://phabricator.services.mozilla.com/D70911
--HG--
extra : moz-landing-system : lando
The semantics of sticky items are somewhat different from the semantics of
fixed items. For fixed items, if an item is fixed to eTop or eBottom or
eTopBottom, it is *always* fixed to those sides. For sticky items, however,
the sides actively stuck to are dependent on the scroll position. So we need
a mechanism to dynamically figure out which sides are stuck, and use those
sides when computing the fixed margins to apply. This patch implements that
by modifying the IsStuckToRootContentAtBottom method into a
SidesStuckToRootContent method.
Differential Revision: https://phabricator.services.mozilla.com/D70910
--HG--
extra : moz-landing-system : lando
I couldn't understand what it was doing before, but conceptually it should
be pretty simple.
Differential Revision: https://phabricator.services.mozilla.com/D70909
--HG--
extra : moz-landing-system : lando
