Two specific changes have occurred with Stylo:
* `lineText` is no longer set because it caused performance regressions to
compute it and it is currently unused by DevTools.
* `columnNumber` is computed differently with Stylo. It's currently the
beginning of property, instead of the end. Bug 1378861 is filed for future
improvements to this info.
MozReview-Commit-ID: 5vTdjNbuhXe
--HG--
extra : rebase_source : 402f957c431f47234ab83acbf3375d66ecabaf16
We were parsing @page rules correctly and serializing for cssom when we
we need. But we weren't actually including them to the pseudo element
declarations when we need to print a page.
Reviewed by emilio on Bugzilla.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1394035](https://bugzilla.mozilla.org/show_bug.cgi?id=1394035)
Source-Repo: https://github.com/servo/servo
Source-Revision: 094502e55f246b7c21d788385dda5c350ecf783a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4cdf6a525dab8d4e204dcc8e4218794e2a9e37b0
The goal of this patch is to ensure that:
- in default placements, specials have no unique ids
- in actual placements as stored by CUI, they do
- we reset the counter for those unique ids on reset.
- we re-number specials when building an area (like on startup, or when resetting),
ensuring that the actual nodes always match the placements for a given area.
- we force saves after resetting, to ensure that the gNewElementCount is always persisted correctly.
This last part will also fix bug 1393661
MozReview-Commit-ID: HAS5J5ZSgB5
--HG--
extra : rebase_source : df62441169e07fb94e39f68a2b3e43f6ed7f464c
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 1d40653b8117e28d8633134f379540c3c517a306
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : f84c5799c305a4a3b7dc5deb727a05d4d537bb15
Now that we have a helper function to obtain a BuildReader, let's
put it to use.
MozReview-Commit-ID: 7V3RsWs5TPu
--HG--
extra : rebase_source : 23193a1482ebb2fc4d1bdc588d8cd31c4d458645
The code for obtaining a BuildReader for evaluating moz.build files
is generic and non-trivial. We already had a custom implementation
for `mach file-info` that implemented support for Mercurial
integration. Bug 1383880 will introduce a second consumer.
So this commit factors out the "obtain a BuildReader" logic into
a reusable function on our base MozbuildObject class. This makes
it easily available to various parts of the build system and mach
commands.
As part of the change, we detect when ``.`` is being used as the
revision and verify the working directory is clean. This behavior
can be disabled via argument if unwanted. But it's useful by default
to ensure consumers aren't expecting to read uncommitted changes.
MozReview-Commit-ID: LeYFqAb3HAe
--HG--
extra : rebase_source : d5ed4e4f5570a58a68853188de2225cd4e64ab3a
This is generally useful functionality to have. A consume will be
introduced in an upcoming commit.
MozReview-Commit-ID: 4arTMfJSiEC
--HG--
extra : rebase_source : 4bcf70f58b57b79b8dcb7a6eed633e1c7e42aca3
It seems reasonable to expose this outside of the BuildReader.
MozReview-Commit-ID: 4paDbYl9dEd
--HG--
extra : rebase_source : 86bb559500952a40fc9afbf958be5706dd9f858e
Profiling shows this reducing parsing time by a few milliseconds on the tp6 facebook case. The gtest benchmark with the same concatenated stylesheets also shows a significant improvement.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 5e321cadf3308d21c4bc7de5061c5fc08670c18a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 17ce55c55bfcc6ed09c0378fbb9832983625a776
Properly enclose all relevant details of CPUUsageWatcher in ifdefs
which control whether it should be active or not. Additionally,
apparently clock_gettime is not defined on OSX prior to 10.12, so
this is failing to compile for OSX on the build server, but not
locally. However, clock_get_time and getrusage should cover our
use cases sufficiently.
MozReview-Commit-ID: Ffi6yXLb9gO
--HG--
extra : rebase_source : 84f9cf3b2074883dc6fe6d5a50ff27ffdb008a4f
We would like to be able to see if a given hang in BHR occurred
under high CPU load, as this is an indication that the hang is
of less use to us, since it's likely that the external CPU use
is more responsible for it.
The way this works is fairly simple. We get the system CPU usage
on a scale from 0 to 1, and we get the current process's CPU
usage, also on a scale from 0 to 1, and we subtract the latter
from the former. We then compare this value to a threshold, which
is 1 - (1 / p), where p is the number of (virtual) cores on the
machine. This threshold might need to be tuned, so that we
require an entire physical core in order to not annotate the hang,
but for now it seemed the most reasonable line in the sand.
I should note that this considers CPU usage in child or parent
processes as external. While we are responsible for that CPU usage,
it still indicates that the stack we receive from BHR is of little
value to us, since the source of the actual hang is external to
that stack.
MozReview-Commit-ID: JkG53zq1MdY
--HG--
extra : rebase_source : 16553a9b5eac0a73cd1619c6ee01fa177ca60e58
When ok() is passed false, we send a message to the parent, which will
cause the test to fail. Throwing in this helper in the child just
makes the test hang for a while.
MozReview-Commit-ID: 4gwBACPYfDO
--HG--
extra : rebase_source : 10f1ee6d013fc731a4bf5bb8365924723e19f9ca
In bug 1356705, we switched scrollbox to use CSS smooth scroll when
the scrollbox is configured to scroll smoothly. This caused the tab
strip to scroll with a "pulse" when using the arrow scrollbuttons.
This is because we scroll by a single tab each time, as opposed to
scrolling by pixels.
This reverts part of bug 1356705 so that we use instant scrolling
instead of smooth scrolling in the scrollbuttons case, which returns
the original behaviour of the strip without the pulse.
MozReview-Commit-ID: D8QQ8kQ7AjM
--HG--
extra : rebase_source : 400f0085b4b914003bfb2a235d2c62bc0f53ab66
Mozjemalloc uses its own doubly linked list, which, being inherited from
C code, doesn't do much type checking, and, in practice, is rather
similar to DoublyLinkedList, so use the latter instead.
--HG--
extra : rebase_source : 7f2c03d6ba5c1da5d8badb0de710b7900e9d00c1
While the flexibility of the current trait is nice, it's actually not
used to its fullest anywhere, and is boilerplate-y. While it is useful
to be able to put the links anywhere, there's not much usefulness from
being able to split mNext and mPrev.
So instead of a trait that allows to get/set mNext and mPrev
independently, we just use a trait that tells how to get a reference to
a DoublyLinkedListElement from a list element itself.
--HG--
extra : rebase_source : b7d502754a764670e291acdd56726948db935497
This is a practice commit to clarify what arguments we're accepting.
MozReview-Commit-ID: 2qQbNAYzGwr
--HG--
extra : rebase_source : 26527c08c32d79f794601afdd7832fa0ed53ecf7
This reduces the size of the code in libXUL by 23.4k according to bloaty.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: af587e5f84cabaa9fd500438adb1d24218b898e2
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 609c1d31dcd6bfc910510c92a93a1df4b9a4be7a
This adds an integration test for the CSS rule column issue from bug
1390455. The fix was landed in upstream rust-cssparser.
MozReview-Commit-ID: 34rLhe3BCqx
--HG--
extra : rebase_source : 2b2bcf88ca3a2ba2b90bc703d7c4e07a2422ca7f
Two specific changes have occurred with Stylo:
* `lineText` is no longer set because it caused performance regressions to
compute it and it is currently unused by DevTools.
* `columnNumber` is computed differently with Stylo. It's currently the
beginning of property, instead of the end. Bug 1378861 is filed for future
improvements to this info.
MozReview-Commit-ID: 5vTdjNbuhXe
--HG--
extra : rebase_source : 7a21eacb97b89f067d448c252c5e8a4e4307889c
Adds index to moz_bookmarks.dateAdded for use by Highlights query for recent bookmarks.
MozReview-Commit-ID: 7Gs8H0kUij2
--HG--
extra : rebase_source : 23498bcde4faeeb116c534dc9e124429a86d3e14
Add helpers for shared adjusting limit, bookmarkGuid sub-SELECT, WHERE and params. More efficiently select https and correctly select bookmarks. Remove _addETLD, getHistorySize and getBookmarksSize. Allow for activity stream caller to customize more options.
MozReview-Commit-ID: Lj9AhoFJar
--HG--
extra : rebase_source : fb4bb13969b47c28c1a137075304efb23c254182
I noticed this error message on fixing dom/workers/test/test_suspend.html:
WARNING: NS_ENSURE_TRUE(mDocViewer) failed:
file layout/base/nsDocumentViewer.cpp, line 3863
It happens when a nsDocumentViewer::Close() is followed by a
nsDocumentViewer::Open(), the viewer would have been disconnected. Since it
takes only one-line change to fix I just include it in this bug.
MozReview-Commit-ID: LMT2PJkUqi1
--HG--
extra : rebase_source : cff6ccb42610cfdcaaf0ab58aa16751e78bdc9a4
browser.sessionhistory.cache_subframes has been disabled for 12yrs. It's not
actually maintained and it leaks content viewers. Using this unreliable feature
in test cases is a bad practice, so remove the pref completely and fix existing
test cases.
MozReview-Commit-ID: 3tQLpsqmmaq
--HG--
extra : rebase_source : 567e01703983ef91a66fb35fdb7702d06ed3c6e4
This duplicates all the win32 includes except pthread.h into a new directory
for MinGW. MinGW needs all the same dummy includes _except_ it needs its
own pthread.h for winpthreads.
MozReview-Commit-ID: AlIvHhFoSIS
--HG--
extra : rebase_source : aba50e79b0be3bc7306bd32b4010076a8ca1184b
Reviewed by xidorn in https://bugzilla.mozilla.org/show_bug.cgi?id=1386900.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [bug 1386900](https://bugzilla.mozilla.org/show_bug.cgi?id=1386900).
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: a7ea6741d38388bc562d5b1cb53e4bf581f6fafe
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f5ac669e2aab0e477c7dd36dcb0de4b17ef40553