We need to delay the response from the setWindowRect command until the
window has had time to properly resize. But because the DOM resize
event is not synchronous, we cannot rely on it alone to tell us when the
widget toolkit has actually completed the resizing.
To overcome this problem we throttle the event using
ChromeWindow.requestAnimationFrame to force the event loop to flush
before resolving the promise.
The setWindowRect command previously relied on a 15 FPS setTimeout delay
because requestAnimationFrame did not work with ChromeWindow, but this
seems to have since been fixed. Local tests show that this approach is
more stable and produces less intermittent results.
MozReview-Commit-ID: D1ICb3F6vX3
--HG--
extra : rebase_source : ef5ef15db80ce78284672551581ce5d9cdde9189
Bug 1370576 disabled staging of application updates, which is not yet
supported in our firefox-ui update tests. As result there is a hang and
the restart button is never clicked on.
This is just a wallpaper fix and full support might still have to
be integrated if wanted.
MozReview-Commit-ID: 8LF1RKxnMEb
--HG--
extra : rebase_source : 5a268cd891a6577eda163c86fe6ef94fe767fbff
macOS doesn't really have a maximized mode; it has a "zoomed" mode which we treat as "maximized" sizemode, and it has a fullscreen mode. When you zoom a window, it's supposed to resize to its "natural" or "best" size, which is for most apps the smallest size that does not require scrolling. In Firefox we just say that filling the whole screen is our "best" size. But if a window is zoomed, you can still move it by dragging its title bar. For example, you may want to do that if you want to move it to a different screen.
Mac apps usually don't change their appearance at all if they enter the "zoomed" size. They only do that if you make the window fullscreen. The native full screen mode on Mac is much closer to the maximized mode on Windows than the zoomed mode is.
Recent versions of macOS have changed the default action of the green window button to be fullscreen instead of zoom. You can now only zoom windows by double clicking the title bar or clicking the green button while holding Alt.
MozReview-Commit-ID: IBu2fBNeuil
--HG--
extra : rebase_source : 1e2fa2af658edaf19a8cb6e6da39a1187c09b833
Gathering this data point takes up to 100ms on reference hardware and might impact
startup performance.
MozReview-Commit-ID: 32sd5uUF08N
--HG--
extra : rebase_source : a80da25b384b47995cc25db9a711ef02ca5842cd
This is the Servo side change for [bug 1372488](https://bugzilla.mozilla.org/show_bug.cgi?id=1372488).
Source-Repo: https://github.com/servo/servo
Source-Revision: 32f82959f89ccd0d6f92058f22f11f2cc7d21d52
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 64ef1f0cba8d44b9451874cd5aec2a851fb1fdfd
We test the expected behavior base on the pref,
"security.data_uri.unique_opaque_origin".
We run the legacy test when the pref is off, however if the pref is on,
we run the new behavior, loading an iframe with X-FRAME-OPTIONS in a
data: URI should be blocked.
Move the data URI in 'if_no_scripts' and 'if_scripts' to seperate files.
Also remove the test 'if_19', as it seems redundant, it tests the same
thing with the iframe 'if_scripts', and it also lacks of 'allow-scripts'
in its sandbox flag.
A mochitest browser test for image blocking.
We query the blocking status by reading imageBlockingStatus.
See nsImageLoadingContent.cpp for the logic of blocking image.
In this test we verified the following behavior:
1. image is loaded.
2. image is blocked.
3. mCurrentRequest doesn't have size yet, so it should be replaced.
4. mCurrentRequest already got size, the following request should be a
pendingRequest.
Use a boolean to prevent calling SetBlockedRequest asynchronously.
Also use the same boolean to prevent some evil code reenters LoadImage.
Then we should redesign the correct bahavior in those follow-up bugs,
Bug 1353685 - Should ServiceWorker call SetBlockedRequest
Bug 1353683 - consider calling SetBlockedRequest in nsCORSListenerProxy::UpdateChannel
Bug 1371237 - consider calling SetBlockedRequest in nsContentSecurityManager::CheckChannel
The problem is if we found a cache hit, then we could go through
ValidateRequestWithNewChannel to validate the cache.
Then if the CSP check fail(asyncOpen2() will fail), then the
imgRequestProxy will remain there, and cause the timeout.
I run into problem when running mochitest
browser/base/content/test/general/browser_aboutHome.js in non-e10s mode.
In the beginning, browser.xul will load defaultFavicon.png, will create
an image cache there.
Next time when the test starts to run, when it loads about:home, then it
will try to load defaultFavicon.png, it will found an image cache hit
(loaded previously by browser.xul), and call
ValidateRequestWithNewChannel there, however the asyncOpen2 call failed,
and the imgRequestProxy is added to the loadGroup of about:home, and
never be notified until timeout.
As a follow-up from bug 1206961, we will remove calling CanLoadImage in
this bug. Also in the case of CSP check failed, we will call
SetBlockedRequest in those cases.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1267075#c30 for the
analysis between the old and new setup.
<!-- Please describe your changes on the following line: -->
spec: https://html.spec.whatwg.org/multipage/#htmlconstructor
---
<!-- 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#17194 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- 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: c58bcc23ea5c4b5f83944e111ce9a2d0ec2b5400
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2ee613be5c136e0376b935ff4d5de918731cb44b
