Implemented the manual linting fixes for docshell/test/navigation, docshell/test/unit and docshell/test/unit_ipc
Depends on D9430
Differential Revision: https://phabricator.services.mozilla.com/D10080
--HG--
extra : moz-landing-system : lando
Enabled ESLint for:
* docshell/test/navigation/**
* docshell/test/unit/**
* docshell/test/unit_ipc/**
Changed .eslintignore to allow for this and ran ./mach eslint --fix on the above directories and checked automatic fixes
Differential Revision: https://phabricator.services.mozilla.com/D9430
--HG--
extra : moz-landing-system : lando
The iterator returned by reversed() can apparently return None in
some configurations. WPT treats this as an in-test skip and errors
the test. To avoid this configuration-specific problem we use a
literal list.
Differential Revision: https://phabricator.services.mozilla.com/D11159
--HG--
extra : moz-landing-system : lando
This generates several new things:
* store_count and store_offset in the HistogramInfo struct.
store_count indicates the number of stores the histogram is registered in.
store_offset is an offset into the gHistogramStoresTable array.
If store_count == 1 && store_offset == UINT16_MAX, then the histogram is only in the main store.
* gHistogramStoresTable: An array containing the actual offsets into gHistogramStringTable to get a store's name
Depends on D10921
Differential Revision: https://phabricator.services.mozilla.com/D10922
--HG--
extra : moz-landing-system : lando
This generates new things:
* store_count and store_offset in the ScalarInfo struct.
store_count indicates the number of stores the scalar is registered in.
store_offset is an offset into the gScalarStoresTable array.
If store_count == 1 && store_offset == UINT16_MAX, then the scalar is only in the main store.
* gScalarStoresMap: An array containing the offsets into gScalarsStringTable to get a store's name
Depends on D10920
Differential Revision: https://phabricator.services.mozilla.com/D10921
--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
Depends on D10586
Adds a new `type` param to the `change` object passed from server to the client to describe the change type. For changes to rules, the client marks the whole rule as either added or removed and styles it accordingly in the Changes panel.
Change types for declarations are not used at this time, but are put in for consistency and future-proofing.
Differential Revision: https://phabricator.services.mozilla.com/D11116
--HG--
extra : moz-landing-system : lando
Depends on D10585
Renames the logChange() to logDeclarationChange() to distinguish it from the newly introduced logSelectorChange() method which tracks selector rename by logging two changes: a whole rule remove using the old selector and a whole rule insertion add using the new selector.
MozReview-Commit-ID: 9VoVMHYXumE
Differential Revision: https://phabricator.services.mozilla.com/D10586
--HG--
extra : moz-landing-system : lando
Depends on D10584
Other methods for tracking changes need to make use of the CSS rule
metadata (selector, rule index, ancestors, etc). This extracts that
logic into an accessor on the StyleRuleActor to facilitate reuse.
The CSS rule metadata will be augmented with information about a CSS
change (declarations added or removed) before being tracked.
MozReview-Commit-ID: xXec1XgUhk
Differential Revision: https://phabricator.services.mozilla.com/D10585
--HG--
extra : moz-landing-system : lando
Depends on D10582
Improves the reducer for tracking CSS changes to handle more than one
CSS declaration changed in one operation. This is a requirement for
tracking whole rule removal or whole rule addition, like it happens
when renaming a CSS selector in the Rules view.
MozReview-Commit-ID: 25pf2GRiH4D
Differential Revision: https://phabricator.services.mozilla.com/D10584
--HG--
extra : moz-landing-system : lando
This isn't strictly necessary for this patch series, but it adds an
optimization to improve performance for React rendering and solves
warnings thrown while using React in dev mode.
MozReview-Commit-ID: ujqOa9qUsd
Differential Revision: https://phabricator.services.mozilla.com/D10582
--HG--
extra : moz-landing-system : lando
In many places we were using bounds to calculate an objects dimensions but that obviously doesn't work when an object is rotated e.g.
{F588303}
Also, we were using `getBoxQuads()`, which gives the co-ordinates of the translated object. We were then applying the transform matrix to the canvas even though the coordinates came from the object **after** it was already transformed.
Anyhow, now we get the dimensions of objects as if they are not transformed and then apply the transformation matrix, which gives a great result every time.
Differential Revision: https://phabricator.services.mozilla.com/D9805
--HG--
extra : moz-landing-system : lando
When Selection is NOT collapsed, we remove selected content. Therefore,
web apps don't need to know range information of user operation. However, web
apps may want to know direction of the operation (backward or forward). E.g.,
web apps may just mark selected range as "deleted" and move caret before or
after the range.
Therefore, when computed EditAction is eDeleteWordBackward or
eDeleteToBeginningOfSoftLine, we should use eDeleteBackward instead. When it
is eDeleteWordForward or eDeleteToEndOfSoftLine, we should use eDeleteForward
instead.
Note that only on Windows, we follow behavior of richtext control (and Word).
That is, Ctrl + Backspace/Delete collapse from start of selected range to
start/end of current word. I.e., collapsing Selection to start first and
removing to start or end of current word is Windows's standard behavior.
Currently, we do this in DeleteSelectionAsSubAction() but every caller
specifies eNone to aDirection except DeleteSelectionAsAction(). So, we can
move this before re-computing EditAction in DeleteSelectionAsAction().
Differential Revision: https://phabricator.services.mozilla.com/D10992
--HG--
extra : moz-landing-system : lando
So that we don't generate anymore unnecessary change hints in
RestyleManager::AddLayerChangesForAnimation for the layer has no corresponding
animations.
Depends on D11105
Differential Revision: https://phabricator.services.mozilla.com/D11106
--HG--
extra : moz-landing-system : lando
