This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
We have a fair number of files that have a particular stale version of the MPL
boilerplate. (It was probably originally correct, and then the official
boilerplate changed, and the stale MPL boilerplate continued to propagate via
copypasting from neighboring files into newly-added files.)
This patch updates this stale MPL text (and *only* the MPL text) to the latest
version, which can be found at https://www.mozilla.org/en-US/MPL/headers/ and
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: 8WeBb8b0uRo
--HG--
extra : rebase_source : 2c3aa8d07ba23714501c9e26ad03625aeab36a7a
(This brings these lines into conformance with our standard style for mode
lines, and it's required in order for the modeline.py script to be able to
process these files.)
MozReview-Commit-ID: KqppMKF1jHv
--HG--
extra : rebase_source : 831b29574d66b66b8104f29b5b5c538241e95eba
Note that I'm intentionally *not* leaving a blank line between the license
block and the "IWYU pragma" line, in nsDisplayItemTypesList.h. This matches the
prevailing style that I found in other files that have "IWYU pragma" lines.
I copied the boilerplate comment directly from the Coding Style MDN page:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
MozReview-Commit-ID: ACoHkDFe8Z3
--HG--
extra : rebase_source : 374d28fea72cfb76043bde724120877b15092d01
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
As per the TODO, a size change on an image is supported now, so there should be
no need to delete and re-create the image key when the window overlay image
changes size. And since the cleanup function is not invoked from anywhere else
it can also be removed.
MozReview-Commit-ID: JSmK5YmXjlX
--HG--
extra : rebase_source : 0078ccfed9a381c82bcb906a87bdf58d8e9c78e1
The window buttons are drawn as part of the AddWindowOverlayWebRenderCommands
function which is invoked in the full-transaction codepath. It should be possible
to have the empty transaction codepath simply update the image (without building
a full WR display list) and do a recomposite. That would be more performant but
it requires some plumbing to build and ship across a IpcResourceUpdateQueue on
empty transactions.
MozReview-Commit-ID: 2Mrb0wELD6E
--HG--
extra : rebase_source : 9a94c32f94403050835bf3445176f4fe2c1579fa
This is functionally unrelated to the bug but I noticed it while fiddling with
the code, and the lines affected are kind of intertwined with the next patch so
I'm just doing the code removal as part of this bug.
MozReview-Commit-ID: CwmluhyCdbR
--HG--
extra : rebase_source : 0a86ba7299f63587b77c44fadc804e34ada5a474
For example, in dom/base/nsGkAtomList.h, we currently have:
`GK_ATOM(mouseWheel, "mouseWheel") // For discrete wheel events (e.g. not OSX magic mouse)`
but if we change to
```
GK_ATOM(mouseWheel,
"mouseWheel") // For discrete wheel events (e.g. not OSX magic mouse)
```
The parser didn't handle the declaration
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] 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: d0213b21113dbb0abeb9e121d16985256167ec62
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 6a54f6c056ab20a022640cf6345e4573f63a0e67
This patch exposes the Places `hash()` SQL function to JS.
MozReview-Commit-ID: C4Zj4FyMZpq
--HG--
extra : rebase_source : 3ea61f17bbdfc5fd18a8bdcf6372a41e1b6e9716
When getting a session cookie we expect 'expiry' to be either null, or
to be missing.
MozReview-Commit-ID: JmSfrR0ypya
--HG--
extra : rebase_source : e24948efec8013b9b4c02ab9573f9c317130cd89
Make CSD setup and titlebar drawing available when users enable it by preference and also it's available on running system.
MozReview-Commit-ID: 4BLgzVWwX1R
--HG--
extra : rebase_source : 15293821b9962bd9d0ee22331e7fad9027a47a7a
IAccessible2_2::get_attribute is not implemented yet in Gecko.
However, the handler still passes this through, thus resulting in a pointless cross-process call.
Instead, just return E_NOTIMPL in the handler for this method.
MozReview-Commit-ID: 5XHieUC4cuz
--HG--
extra : rebase_source : 814ceda6d9dd4ec26f05a4ff90bbd4af2a6eb84e
The reftest box-decoration-break-with-inset-box-shadow-1.html was affected
by both PR 1910 and PR 1918.
The reftest backface-visibility-2.html was affected by PR 1914.
MozReview-Commit-ID: JFwhmttGJjQ
--HG--
extra : rebase_source : 7e716a64aa0de2f862b9bea7c0d30131e92ba319
When the New Tab page is opened, the browser object that is passed into the isArticleChangeListener
is not a valid browser from the perspective of tabbrowser.xml, so it is not able to find it in its
_tabForBrowser map. This causes undefined to be passed into tabManager.getWrapper(), which causes
the error.
This patch fixes this by not calling tabManager.getWrapper(), and subsequently firing the onUpdate
event, if the return value from gBrowser.getTabForBrowser() is undefined. Testing shows that that
is only the case when the New Tab page is opened, and that page is not, and is unlikely to be
readerable any time in the foreseeable future (confirmed on IRC), so ignoring this case in the
listener is acceptable.
MozReview-Commit-ID: D9LQRrPmCoU
--HG--
extra : rebase_source : da5c074c2e59babb5385d24a4f768aa4b7ae8997
This works by allowing an extension to set a value of Services.perms.DENY_ACTION
for permissions.default.desktop-notification, which stores the default permission
for desktop notifications. This means that if no permissions have been explicitly
set for a given page, the default will be used, but if a user overrides the permissions
for a specific page then their chosen permission will override this default.
An extension can only use this to make the default behaviour to disable notifications.
It cannot be used to globally enable notifications.
MozReview-Commit-ID: H5bDZe1ICiC
--HG--
extra : rebase_source : 24022d3ce5d0eba245099881f762e1f6353c50cb
