This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_SET_INCOMPLETE\(\*([a-zA-Z0-9.*]*)\)" "\1->SetIncomplete()"
rename "NS_FRAME_SET_INCOMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.SetIncomplete()"
MozReview-Commit-ID: GOd4y2N6dcz
--HG--
extra : rebase_source : 185f5d6f5a3c8306761860c579eff10d931f3b35
This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_OVERFLOW_IS_INCOMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.IsOverflowIncomplete()"
MozReview-Commit-ID: GOd4y2N6dcz
--HG--
extra : rebase_source : 2945ff0274d91137249eb2b5a053eeec08864a25
This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_IS_COMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.IsComplete()"
MozReview-Commit-ID: GOd4y2N6dcz
--HG--
extra : rebase_source : aa8b11d3a756c9e7c521e6ffd70713af0174bd98
This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_IS_FULLY_COMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.IsFullyComplete()"
MozReview-Commit-ID: GOd4y2N6dcz
--HG--
extra : rebase_source : 200639e836cebe26fd77cde21f478fd027e1725f
This patch is written by the help of the following script.
function rename() {
find layout\
-type f\
\( -name "*.cpp" -or\
-name "*.h" \)\
-exec sed -i -r "s/$1/$2/g" "{}" \;
}
rename "NS_FRAME_IS_NOT_COMPLETE\(([a-zA-Z0-9.*]*)\)" "\1.IsIncomplete()"
MozReview-Commit-ID: GOd4y2N6dcz
--HG--
extra : rebase_source : 412b60e7954118d8443ebf2a786046d7cd38c516
Lay down the foundation for this refactor work so that nsReflowStatus could
be converted to bit-fields piece by piece, and each patch can be built (but
may not pass tests).
This change causes some build warnings, due to some debug logs printing
nsReflowStatus as an integer, but that will be fixed by Part 24 later.
All the operators related to uint32_t will be removed at the end of this
patch series by Part 23.
The yoda conditions are swapped in order to build successfully.
DisplayReflowExit() incorrectly declares aStatus as uint32_t. Change it to
const reference because nsReflowStatus is now a class.
MozReview-Commit-ID: 5DOpaP85ywJ
--HG--
extra : rebase_source : 53ca0750b5f764fcbf7ba2d00c9ec606aed704c2
If we don't have any alive track in MediaTrackList, we don't need to mute
MediaElement.
MozReview-Commit-ID: 9vY692O7N0e
--HG--
extra : rebase_source : 3abd2fb360385b1975dbffd9dcaf4e395b1afda1
The DOMAudioPlaybackStarted event would affect the tabbrowser's attribute,
"soundPlaying", and this attribute should indicate whether the tab is audible or not. However, in present codebase, even the tab has "soundplaying", it doens't mean
the tab has audible sound, you need to check extra attribute, "muted".
After applying this patch, tabbrowser can only own one of the attributes ("soundplaying"
or "mute"). These attributes won't exist at the same time, so we can easily know
whether the tab is audible by checking "soundPlaying".
Let's see an example,
step1. playing a playing audio
- tab owns "soundPlaying"
step2. mute the tab
- tab owns "muted"
step3. stop audio
- tab owns "muted"
step4. replay the audio
- tab owns "muted"
step5. unmute the tab
- tab owns "soundPlaying"
step6. stop audio
- tab owns ""
MozReview-Commit-ID: EEKEbAVzsVm
--HG--
extra : rebase_source : 823d501e9162ae8b611f2e97dd763c1eec16c2cf
The root cause of the intermittent fail is because "DOMAudioPlaybackStopped" has no directly relationship with browser.mute()/unmute().
In [1], the "DOMAudioPlaybackStopped" is caused by audio stop playing, not by calling the browser.mute(). If the audio stops playing before calling the wait_for_event(), the test would be time-out. I guess the bug 1302280 is also caused by same reason.
So this patch would do two thinngs,
1. dispatch "DOMAudioPlaybackStopped" when we mute tab
2. loop the audio in test file, to make sure the "DOMAudioPlaybackStopped" is
dispatched when muting the audio, not the file ended.
[1] https://goo.gl/ymUv8P
MozReview-Commit-ID: 5RnyBRE73lQ
--HG--
extra : rebase_source : 40ad97cbf84da6f5d013d832cb12e3ed88473dfd
Since we don't want to show the media control for the short sound, so we added the duration checking.
And this checking only needs to be run when the media is active, we don't need to check the inactive media.
MozReview-Commit-ID: AaVGi77nXJ1
--HG--
extra : rebase_source : c565fe64ec4030f0519eb0a8cfe493e95bae4fe4
Since BBC website puts their audio in another iframe, we can't get the media
element to check its duration, so we always return false.
The ideal way to fix it is to get every iframe and check its element, but I think
it's not very easy to do considering the flexibility of using iframe and the cost time.
First, if we want to get the information inside iframe, we need to listen the
onload event, but it's async operation. If there are lots iframe, we need to spend
lots time to wait every iframe. The worst situation is we got the nested iframe,
it would need lots time and effect to wait every iframe loaded and get the element we want.
Therefore, I would prefer the workaround which is to reverse the checking condition,
that is we only check duration for the main window.
MozReview-Commit-ID: F93BjbzRMXO
--HG--
extra : rebase_source : 9409649db241b466967ab1e7f467e177c06c728f
The design of initiating network requests from the image cache thread was simple, but it makes it difficult to implement image loading that conforms to the HTML specification. These changes make the implementation of HTMLImageElement responsible for network requests for `<img>` elements, and CSS-based images (background-image, bullets, etc.) are requested by the script thread to ensure that the layout thread does not attempt to retain unsafe pointers to DOM nodes during asynchronous operations.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#7708
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 854d720b21dda68034233a25385c4f2564a4a2d5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 845215025ea28e20cf0372075841172a4ed5206c
There is no need to limit output space bounds in
nsFilterInstance::OutputFilterSpaceBounds(), it's just far too early.
MozReview-Commit-ID: 9i9huKDGxq6
--HG--
extra : rebase_source : 3f7a16fe27f661e79087c6a302235b01f65169d5
r? @Manishearth
I don't have a good sense for creating syntax... so if you have any suggestion for the syntax of `impl_arc_ffi` macro, it would be appreciated.
Source-Repo: https://github.com/servo/servo
Source-Revision: af292c4a7180a35c632b16a4fb0aff9ae2933f77
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5be76e20de735b8762a89b5e3ef88ded550ad81a
Also only show the separator between code and message if there actually is a
message.
MozReview-Commit-ID: 6Cb4YnFi2fT
--HG--
extra : rebase_source : 98183484972fa1c910f0e5e7fe4d46c763e97eb8
Since these are used in diagnostic messages intended for developers, more
detailed information should help with distinguishing some issues. E.g.:
Before: "Init"
After: "virtual RefPtr<MP4Demuxer::InitPromise> mozilla::MP4Demuxer::Init()"
MozReview-Commit-ID: TgNNn66Ilj
--HG--
extra : rebase_source : 572af3a82d046bb790c4b54e13bc45451229c9e0
Ting-Yu Lin
Alastor Wu
Phil Ringnalda
Aaron Klotz
Tom Klein
Andrew McCreight
Alfredo.Yang
Shane Caraveo
Josh Matthews
Boris Zbarsky
cku
Xidorn Quan
David Keeler
Brian Birtles
Gerald Squelart
Wes Kocher
Tom Schuster
Kai Engert
Daniel Holbert
ffxbld
Carsten "Tomcat" Book
Sebastian Hengst
Iris Hsiao
Jonathan Kew