Open a GetOwnerDoc() method to the MediaDecoderOwner interface and then we can get the
owner document via a pointer to MediaDecoderOwner in MediaDecoder.
MozReview-Commit-ID: JCzQDLx1MsU
--HG--
extra : rebase_source : e194c95cb1513046ec7aa19d6c6e9f8231971a2d
extra : source : 1b9c45911a036e3677b6636cda84a636681d71de
Instead of calling DownloadSuspended() via a pointer to a HTMLMediaElement,
we should call DownloadSuspended() via a pointer to a MediaDecoderOwner.
MozReview-Commit-ID: BvExQuchsWb
--HG--
extra : rebase_source : 0c8a5d412e91e2c370050a4706fc6f2afc0c20e9
extra : source : fb5ca26fc018e273296411a037b70b922cb26f4d
<!-- Please describe your changes on the following line: -->
- Fix crop_area_bytes_length calculation (the height was multiplied by itself)
- Add tests for this error and for the case that the width is multiplied by itself
---
<!-- 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#15386
<!-- Either: -->
- [X] There are tests for these changes
<!-- 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: 594a679002a5d74da761c17574ad5383a130b55a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 58e86c96aa98b7de2754d8687a68893b66d8fe7a
mTelemetryProvider might be empty if |CancelUpdate| is called during update.
In that scenario, the call flow will look like:
CancelUpdate -> UpdateError -> DownloadDone -> set mTelemetryProvider to empty ->
OnStartRequest -> record telemetry with empty key.
So in this patch, move mTelemetryProvider.Truncate() to OnStopRequest.
MozReview-Commit-ID: JDgNUqR4SKa
--HG--
extra : rebase_source : 42aa4c898f403a1189e67e355246ebed5aa4af44
Now that we don't support XP it's reasonable for us to drop support for GDI
fonts and rely solely on DirectWrite. We should start this process by removing
support for building without DirectWrite.
UIEvent.isChar is not supported by the other browsers and the value isn't initialized any platforms except on macOS. So, the value isn't useful and we have no reason to keep it.
MozReview-Commit-ID: 4BLpo88gSZj
--HG--
extra : rebase_source : ca950f8cb618a0cadc99ba4c80b5a8df94a20f27
When nsRange::*JS() is called, mCalledByJS is set to true. In such case, Selection::NotifySelectionListeners() may move focus or anyway, it calls selection listeners. Then, they may cause calling non-*JS() methods of the nsRange instance. In this case, nsRange treats the call as called by JS since mCalledByJS is still true.
For preventing this issue, before calling Selection::NotifySelectionListeners(), nsRange should set mCalledByJS to false.
This patch renames AutoCalledByJSSetter to AutoCalledByJSRestore and make it stop setting mCalledByJS automatically. So, AutoCalledByJSRestore works same as AutoRestore now.
MozReview-Commit-ID: IYsbQTGp3VA
--HG--
extra : rebase_source : 582eb2288c035861f16149dde42c22aba555bb5a
This patch enables flake8 rule E222:
"multiple spaces after operator" in toolkit/components/telemetry
by removing the relative E222 entry from toolkit/components/telemetry/.flake8
and fixing the files for which the E222 error was reported.
Precisely 1 error violating E222 rule was found and solved.
MozReview-Commit-ID: 3xx09jkVu3E
--HG--
extra : rebase_source : 23c7ed40161e843ebe1b47fead2b00e4550b90ff
Enable the rule with the maximums set to avoid current failures, except for test_form_autocomplete which is very
high (82). The levels are set per major area, with existing warnings being changed to errors.
MozReview-Commit-ID: 37M6Ry0Mr1c
--HG--
extra : rebase_source : 07e6864bdd945eb322499912dd702638430c0365
Since -moz-element is moz only feature, the test case for -moz-element is
created under reftests/image-element folder.
MozReview-Commit-ID: G4V0G3cX7qr
--HG--
extra : rebase_source : f681d64fe4b9331a35fb082c7ed135f58c3f5a9d
It's ok to pass aRenderingContext to DrawableForElement, since DrawableForElement
only use aRenderingContext to create a similiar draw target. Replace
aRenderingContext by ctx make code more consistent since the draw call
bellow(nsLayoutUtils::DrawImage) use ctx.
MozReview-Commit-ID: 6n0nYfcFPui
--HG--
extra : rebase_source : 1374c8b5be9fe5351a5a126e39773c9493cf233d
If mask-mode is luminace, we will create a temporary context at [1]. It's
obvious we do not use this gfxContext at all in PaintGradient path. This patch is
trying to fix this problem by pass gfxContext, instead of RenderingContext,
directly to PaintGraident.
[1] https://hg.mozilla.org/mozilla-central/file/991f5724e58f/layout/painting/nsCSSRendering.cpp#l5811
MozReview-Commit-ID: LLmg4k6IEm3
--HG--
extra : rebase_source : ed42e3f5ddf1314300259c3f74d43aac8b4683de
There is a bug in this feature which somehow prevents MDSM from reaching the
end of playback and firing the 'ended' event. We will default this feature to
off in media tests and tests for this feature need to turn it on explicitly.
We will also open a new bug to investigate this issue.
MozReview-Commit-ID: 8ebgcHGPKY0
--HG--
extra : rebase_source : f5a7dcf4a80eece6270e2757d7c41e5eaaff60e9
According to bug 1345853 comment 5, tn said:
You probably want to return whatever was drawn there regardless of the
DrawResult. SVGMaskFrame has the same problem. Keep in mind that DrawResult is
only reporting on how drawing of any images went, not the drawing of anything
else. Also looking over the patches from bug 1258510 I see a couple places where
BAD_ARGS is returned if the transform matrix is singular. We would want to
return SUCCESS in that case I think, because we drew what we were instructed to
draw.
MozReview-Commit-ID: 5XcDuKQwXTJ
--HG--
extra : rebase_source : ba764df599844c9eb179736f61d6c7f6ee46c9fc
I did many change in many files in this patch. But the goal is pretty simple: To
pass the return value of nsSVGPatternFrame::PaintPattern back to the caller
(nsDisplaySVGGeometry). My suggestion is to review this patch right from
nsSVGPatternFrame.cpp.
I made two mistakes in bug 1258510
1. We should not return directly at [1]. RemoveStateBits at l418 will be skip.
2. nsSVGPatternFrame::PaintPattern should return both SourceSurface and draw
result, so that we can update UpdateDrawResult in display item.
All the other changes are to
1. make sure the return value of nsSVGPatternFrame::PaintPattern goes back to
nsDisplaySVGGeometry::Paint correctly.
2. Since the return value of nsSVGPatternFrame::PaintPattern change, we need
modify all existed callers.
I also filed bug 1346124 for handle the returning value of PaintMarkers.
[1] https://hg.mozilla.org/mozilla-central/file/c0700bedb4f7/layout/svg/nsSVGPatternFrame.cpp#l415
MozReview-Commit-ID: Iq9RPQ6Omz0
--HG--
extra : rebase_source : bc338b1a33f1dbf209706577b2455315dfb855e2
This change automatically evicts content scripts 5 minutes after their last
use, and flushes the entire cache whenever a memory-pressure event is
received.
In the case of memory-pressure events other than heap-minimize, we only evict
scripts that have been in the cache for longer than 3 seconds (which is a
fairly arbitrary number) in order to prevent pre-loads from being evicted and
then immediately re-loaded.
MozReview-Commit-ID: LCXkI9qVMxS
--HG--
extra : rebase_source : b81ed3b9962346154fa18eaee58a7411244a1936
This uses the http-on-opening-request observer that's dispatched in the child
process to begin preloading matching content scripts as early in the load
cycle as possible. Ideally we would use the network predictor for this, but
most of its prediction work happens in the parent process, and there are no
simple ways for us to hook into it.
This currently does not do any pre-loading in the parent process, mainly
because there isn't a good way to distinguish top-level document loads that
are happening directly in the parent versus those that are being proxied from
the child.
MozReview-Commit-ID: dIQW68HtxZ
--HG--
extra : rebase_source : b36f6c8516d0550a0d5bb0df895ce6db76ab3538
In order to asynchronously load content scripts that need to run very early in
the page load cycle, before any ordinary page scripts, we need to be able to
block parsing from the document-element-inserted listener. Since the script
loader operates by returning promises, blocking on promise resolution is the
simplest way to achieve this.
MozReview-Commit-ID: CTWlyrP6dqG
--HG--
extra : rebase_source : 28ce713a6450c223f9b2089e6c6e8c78284ef8af
In order to asynchronously load content scripts that need to run very early in
the page load cycle, we need to be able to block further parsing from the
document-element-inserted observer, before any page scripts are loaded.
Interrupting the flush loop after the document element is inserted allows
the observers to run, and temporarily block further parsing if necessary.
MozReview-Commit-ID: A6D2T52Mlx4
--HG--
extra : rebase_source : 86f303a0bf298ac32b934290a7f960a2e1bac581
In order to support asynchronous loading of extension content scripts, we need
to be able to exit the HTML parser flush loop immediately after inserting the
document element. Normally this doesn't cause problems, but when we enter edit
mode with an empty element selected, the editor inserts a <br> node, and a
<br> node at the start of the <html> element causes issues.
These changes solve that issue by putting off entering editor mode until we
begin laying out the document.
MozReview-Commit-ID: H2ksNz0jRxs
--HG--
extra : rebase_source : 26e0d254744363f5bd60f3b4f4df7b51c3dc446f
Kaku Kuo
n0max
dimi
Jan-Ivar Bruaroey
Mats Palmgren
Jerry Krinock
Kevin Chen
Mihai Tabara
Joel Maher
Jeff Muizelaar
Masayuki Nakano
Bobby Holley
Federico Padua
Mark Banner
Carsten "Tomcat" Book
cku
JW Wang
Mark Hammond
Xidorn Quan
Kris Maglione
JerryShih
Yura Zenevich