In Bug 1419292, we make sure there is no issue when releasing
actors for the output messages, so the sidebar is probably
good to go on Nighly in order to get more feedback.
The test for context menu entries in the console was updated
since it now shows the "Open in sidebar" entry.
MozReview-Commit-ID: 8R3rhf944Fh
--HG--
extra : rebase_source : e504095a1a5ffee711f81ef3de2b1a4da38b4493
This commit makes the page info window treat cookie permissions a little
differently, to reflect that the "default" value for cookies is a combination
of two prefs that doesn't strictly map onto the ALLOW/SESSION/DENY system of
permissions.
I also added some more general pageinfo permissions tests.
MozReview-Commit-ID: 80vd61Rv867
--HG--
extra : rebase_source : c079e47afb74b2c4b7da271efcaf20dd45d1eb60
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : a130f1cf22973910767e96c69962d8b621c0d368
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : f7cdc1b46fbca96b2124582f29c791f8944c1fc9
- Add Redux setup for storing CSS font property values
- Refactor FontAxis component into generalized FontPropertyValue to
support values with units.
- Generalized CSS selectors to apply to UI other than for font axes
MozReview-Commit-ID: 52LAmhfyxuV
--HG--
extra : rebase_source : c5cc4b1b781a0106213182e164250bc4322c44d3
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : 3e8cc6c9cd6fb79ab1f7ec3d1e38a34a2c7f6011
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : e5643b83914b47889e4bde6c0f8658fedb3d54fc
Bug 1425588 tracks disabled tests for webrender, including a
couple of user prompt tests of the wdspec test suite. The tests
for get_element_property and get_element_tag_name also
intermittently fail, and need to be disabled for now.
MozReview-Commit-ID: AQLxDdqD80p
--HG--
extra : rebase_source : 2d6fd42beb42490f42b1e5de95c060ec15bd07b4
Bug 1446930 added a baseline implementation of memory.fill/copy, and runtime
test cases for them, but missed out validation code and test cases for them.
This is a followup, to add those missing elements.
--HG--
extra : rebase_source : f9c62eadcd9eecd69d58e50a3bd09154dde6f202
Somehow the header files were being installed directly into
$prefix/include, rather than $prefix/include/mozjs-60. Something else
changed somewhere that affected this, since this code was the same in
older mozjs versions, but this seems the most logical place to fix it.
We do the following:
CreateRootNode();
nsresult rv = BindToFrame(this);
NS_ENSURE_SUCCESS(rv, rv);
aElements.AppendElement(mRootNode);
That means that if BindToFrame fails, mRootNode will never be appended to
aElements, and thus will never get the native anonymous bits in [1].
BindToFrame should assert, but it indeed can fail due to it being bound to a
different frame in print preview, because nsCSSFrameConstructor's
ReplicateFixedFrames is a massive hack. :(
Just ensure the NAC bit is properly set for now...
[1]: https://searchfox.org/mozilla-central/rev/a85db9e29eb3f022dbaf8b9a6390ecbacf51e7dd/layout/base/nsCSSFrameConstructor.cpp#4193
MozReview-Commit-ID: 6sE8iUk4PCG
We rely on :hover and :active being hierarchical, and on the fact that there are
only elements and documents in the flattened tree ancestor chain if the element
is in the composed doc.
MozReview-Commit-ID: LMQkidMe9wp
For now just return sans-serif, though as the FIXME comment indicates we should
probably just carry around the font-name instead.
MozReview-Commit-ID: CIPbV3R5Ul
--HG--
extra : rebase_source : ce8666e747341d203d655e937501806c1646331b
This is needed to serialize computed URLs correctly from getComputedStyle.
MozReview-Commit-ID: 9wakhqNrszb
--HG--
extra : rebase_source : 7d120ac0917a5e13de4e52b7dfa0d784495fd8f7
This removes some dubious font-family code too.
It ensures that vector longhands have a proper clone implementation
auto-generating it using `collect()`.
MozReview-Commit-ID: FkdnbTkeF6E
--HG--
extra : rebase_source : 8574eda5b65be614fc2daea8b2ded4c09f0a186e
We probably need more fixes for counters and Shadow DOM. The spec only mentions
"document order", and this is the most reasonable thing to do accounting for
shadow DOM in that regard...
This ensures a reasonable behavior for all callers which pretty much expect
otherwise for all children to be connected.
MozReview-Commit-ID: YEQIKdjRTK
--HG--
extra : rebase_source : 9b31f5d00d270cf21476776144d62350b5453f99
This one sucks. I found out when running tests that we exploit some edge
case behaviour in our tests where passing an invalid value to an xpidl
array parameter will be passed as an empty array...
I figured that just respecting this behaviour for now is the easiest
approach, but we will probably want to fix it in the future.
Current XPIDL native arrays currently also require a custom entry point. With
the new arraylen parameter we can handle them in JSData2Native/NativeData2JS. As
these methods are more complex and don't share logic with an existing codepath,
I keep them in external helper methods.
Tom Ritter
Nicolas Chevobbe
Johann Hofmann
Jan Henning
Kartikaya Gupta
Razvan Caliman
Bogdan Tara
Henrik Skupin
Luca Greco
Gijs Kruitbosch
Emilio Cobos Álvarez
Csoregi Natalia
Julian Seward
J.C. Jones
Philip Chimento
Cosmin Sabou
Tooru Fujisawa
Brindusan Cristian
Geoff Brown
Olli Pettay
Boris Zbarsky
Martin Stransky
Steve Fink
Nika Layzell