Update the test to verify about:newtab should have firstPartyDomain set
when we enable the pref.
We split about:newtab from browser_firstPartyIsolation_aboutPages.js because
about:newtab needs special care.
In the original test browser_firstPartyIsolation_aboutPages.js, when calling
tabbrowser.addTab, if it found out the uri is about:newtab, it will use
the preloaded browser, however the preloaded browser is loaded before when we
turn on the firstPartyIsolation pref, which won't have the pref set.
To prevent to use the preloaded browser, a simple trick is open a window
first.
A missing break statement caused a double execution of the code in
"profile-after-change", which leads to two instantiations of the
Marionette server colliding due to the same port.
MozReview-Commit-ID: Dp6fncj463j
--HG--
extra : rebase_source : dd4301c2fb797da228c0011e6bd90afa9171fb54
The webdriver spec declares the "proxyType" as required, and of
type string.
MozReview-Commit-ID: FXUhdYfOwWI
--HG--
extra : rebase_source : dc069a4de1e014951ed430bf5448ca0e3ac2545e
Most ChannelMediaDecoder::CloneImpl() functions just check to see whether
their "is enabled" pref is still true, and then clone their true type.
If we had a function to check whether the decoder for an arbitrary type
was still enabled, we'd not need the "is enabled" checks in the CloneImpl()
implementations. We'd then have removed the last custom behaviour in the
ChannelMediaDecoder subclasses.
MozReview-Commit-ID: D7kW6kb6ztW
--HG--
extra : rebase_source : 88f259ea0245a4405897959d5c115b0b79dc45e2
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 505f9dce979aad0529b07d2c046dca5028af6de6
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 83d0facbe26f8385c7163dc85d5512e7a43e80f4
MediaDecoder::CreateStateMachine is only virtual so that Ogg can attach
the reader's metadata/seekable produces to its chaining event.
The MediaSourceDecoder also overrides CreateStateMachine(), but it's not
called by anything external, so its implementation doesn't actually need
to be virtual.
MozReview-Commit-ID: 2x6bpK6Fdzd
--HG--
extra : rebase_source : 5a9932bf98992e13ba850dd640d2623ad8bcccbb
This change was reviewed in https://bugzilla.mozilla.org/show_bug.cgi?id=1390773
Source-Repo: https://github.com/servo/servo
Source-Revision: 5964be77217ee42af0558b04af2388080245b72c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 616523133e293be92816bd7df38357fb45504b62
Most ChannelMediaDecoder::CloneImpl() functions just check to see whether
their "is enabled" pref is still true, and then clone their true type.
If we had a function to check whether the decoder for an arbitrary type
was still enabled, we'd not need the "is enabled" checks in the CloneImpl()
implementations. We'd then have removed the last custom behaviour in the
ChannelMediaDecoder subclasses.
MozReview-Commit-ID: D7kW6kb6ztW
--HG--
extra : rebase_source : f463785d2975adceffd62037315d169736effbc0
I noticed that touching MediaDecoder rebuilds a lot of seemingly unrelated
code. This is because HTMLMediaElement includes MediaDecoder.h, and
HTMLMediaElement is included in a number of places. Having HTMLMediaElement.h
predeclare rather than include fixes it.
MozReview-Commit-ID: I0vrPgqvvge
--HG--
extra : rebase_source : 366d4e34e9c425b478b4c9058e27c9a32de36515
We have three implementations, in the MP4, WebM and MediaSource decoders. The
WebM and MP4 are the same. Ogg and other decoders don't have an implementation,
but if we create a default implementation in MediaDecoder, they'll get it for
free. MediaSourceDecoder needs a custom override still.
MozReview-Commit-ID: AXxn2Xhn0Jn
--HG--
extra : rebase_source : 63513ce3b01546142357182f21fce56932b32f7f
MediaDecoder::CreateStateMachine is only virtual so that Ogg can attach
the reader's metadata/seekable produces to its chaining event.
The MediaSourceDecoder also overrides CreateStateMachine(), but it's not
called by anything external, so its implementation doesn't actually need
to be virtual.
MozReview-Commit-ID: 2x6bpK6Fdzd
--HG--
extra : rebase_source : 01b4a59cba8ec64480779fb6849322841646ca3b
<!-- Please describe your changes on the following line: -->
We need to update the links of Match and Patterns in Some basic
Rust section.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because it updates the wiki page.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: e9e032148d1c4f7efd192d78763a0ce61fb47a45
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : b7fba70b042e707b83a7f45a3932c9b5ac50ae17
The reason of the previous failure is we wrongly use default color for drop-shadow
functions that without specified color component. Since this has been resolved in
bug 1388220, we can enable these two tests now.
MozReview-Commit-ID: C3bPcLYQwvW
--HG--
extra : rebase_source : c39d1465658e358110bdccb32649a7fdea4c562c
<!-- Please describe your changes on the following line: -->
We really want to ensure empty rule nodes appear in the rule tree for devtools, this condition ensures that if we find an empty rule node, we insert it at the normal level.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1384802](https://bugzilla.mozilla.org/show_bug.cgi?id=1384802)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because of the test cases are in Gecko.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: dc654c991238305d6fc0524173c85f40d7b9e90f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 75f99790a3111b47d8135d31af42443624426efc
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: LY6z7lEKgOp
--HG--
extra : rebase_source : deb9739bd100e2162e7c93d6d45d7029d7793355
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: 6qqVVfU8Mb2
--HG--
extra : rebase_source : 825985977307b50ae8a80ab182e54a3f7b95eafc
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the callee expects space for the struct
return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: FRBqlZuMiAR
--HG--
extra : rebase_source : d1b2af4b965c000a5bd8e1792ae166cba5e152a9
Rust was treating this as returning an `Owned` types which uses a struct, while
C++ saw it as just a pointer.
This disagreement violates the Linux 32-bit ABI, and also the pointer was deemed
to be more correct anyway.
MozReview-Commit-ID: AQJkdU02vfh
--HG--
extra : rebase_source : d53d7a395944f65d71f14e540cc6d6bac4582187
Bevis Tseng
Yoshi Huang
Henrik Skupin
Chris Pearce
Xidorn Quan
Ting-Yu Lin
gasolin
Phil Ringnalda
Joone Hur
Evan Tseng
Emilio Cobos Álvarez
Wes Kocher
KuoE0
Jeremy Chen
Rex Lee
Mike Hommey
J. Ryan Stinnett
Luke Chang