We wish to enable WebVR only for 64-bit builds before it rides the
trains with 55 in release.
This will serve a few purposes:
- Reduction of test requirements by reduction of configuration matrices.
- Ensuring that the optimal 64-bit builds are used for WebVR sites,
which are often likely to hit 32-bit address space fragmentation
limitations resulting in OOMs.
- Act as a rudimentary soft-launch in 55. 56 is expected to bring a
larger set of users to 64-bit builds.
MozReview-Commit-ID: 207ABcd31dP
--HG--
extra : rebase_source : 5e7ec8d88beb5ecebdf8d5b224b6024d875bd134
This is needed to:
1. force the devtools system addon installation when starting the BT instance of FF
2. avoid the addon update prompt
Another approach is to create a separate user.js pref file to fix 1. However with this
approach there is currently no way to fix 2.
MozReview-Commit-ID: palK2hION0
--HG--
extra : rebase_source : e7a70e68d359fe4a3249a6a5648a52abbde6d851
From console/net/main.js we are calling loadSheet from sdk/stylesheet/utils.
This API needs a real window object to work, but now that devtools are loaded
as a system addon, by default the global object is a sandbox wrapper.
Use the window object which points to the actual Window instead.
MozReview-Commit-ID: LxDNfDiOso3
--HG--
extra : rebase_source : b00465e7e0ef8145b341c495eb27e7f1e703d341
DevTools preferences are loaded dynamically by calling DevtoolsPreferences.loadPrefs().
We can not preload them when the addon starts, otherwise this will slow down the startup
of Firefox.
But jsonview's converter-observer needs to check preferences to check if jsonview is
enabled very early. Moving devtools.jsonview.enabled to a separate preferences file
that is still processed by firefox fixes the issue.
The downside is that this pref will keep following m-c's release cycle and not the addon's.
But it is so generic it should not be a big issue.
MozReview-Commit-ID: HrD5IVe54Ks
--HG--
extra : rebase_source : 7feb021770c827996e276b60169b08093ecc1ff0
DevTools should not execute any code on the browser startup. Loading preferences takes
a non negligeable time and should be deferred to the devtools initialization.
For all devtools entry points, Loader.jsm is always loaded first, so it is safe to
load the preferences here.
MozReview-Commit-ID: Hg4VBj2LqPo
--HG--
extra : rebase_source : 86bfef7e13ecf52b9b8c761fbf7352af42a6bced
In this patch:
- register webide properly
- register localization
- add processing indicator in jar.mn for pref files (details below)
The preferences files still contain processing instructions, that we manually interpret when loading
prefs. Keeping the * processing indicator will avoid triggering warnings in tests scanning
javascript files for issues such as browser_parsable_script.js
MozReview-Commit-ID: 8WYUvbtMNn5
--HG--
extra : rebase_source : 18b13c0d6d1065e141650edb5a3a0b1e7b09a5f8
Missed this in the update in bug 1382743. Thanks to glandium
for pointing out the oversight.
MozReview-Commit-ID: 6P4qnBCNEGy
--HG--
extra : rebase_source : d4b540d27ffaaa2edf5554a641dfc99fc93e9b92
<!-- Please describe your changes on the following line: -->
This is needed for ::first-line support. See https://drafts.csswg.org/css-pseudo-4/#first-line-inheritance
This PR doesn't quite implement what the CSS spec draft says right now. It implements what Gecko does, which is what an earlier draft said.
---
<!-- 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1382806
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because servo doesn't support ::first-line yet
<!-- 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: 020188fdd77f0f0f2848e21eb9bcc28362d98506
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fb65e4b9bd1efb55d0a2a11efd05611ac6d734eb
We don't need to bother with refcounting for these pointers, because they're
pointing to DOM elements, and the DOM is basically immutable during reflow.
And BidiParagraphData is a stack-only class which only lives for a short period
of reflow - so it can assume these pointers' targets will stick around for its
whole life.
MozReview-Commit-ID: J3SfRYoRweX
--HG--
extra : rebase_source : 9ebab968fdb1e4cc30033ab0744d883a9b0d820e
We have a minimum requirement of VS 2015 for Windows builds, which supports
the z length modifier for format specifiers. So we don't need SizePrintfMacros.h
any more, and can just use %zu and friends directly everywhere.
MozReview-Commit-ID: 6s78RvPFMzv
--HG--
extra : rebase_source : 009ea39eb4dac1c927aa03e4f97d8ab673de8a0e
Passing SourceLocation into constructor instead of assigning
immediately after construction cleans up the code and helps to
prevent leaving an invalid SourceLocation in the future.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [X] These changes do not require tests because it's just a cleanup.
Source-Repo: https://github.com/servo/servo
Source-Revision: a15d13a6ec7b1f1ffeef86484ee483ec253ed0ba
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : aa56fb4a8ca1dfb75cda8cef889ee78e7cd5a169
This adds handling for nsDisplayRemote frames, so that we create a
WebRenderLayerScrollData item for each nsDisplayRemote frame that we
encounter. This is the equivalent of a "ref layer" in a normal layer
tree, and allows the APZ side to glue together the scroll data from
different processes into a full tree.
MozReview-Commit-ID: 3lgsqtCKQya
--HG--
extra : rebase_source : eb93be1ef415349e00c09d7274d49fcf7992d197
The semantics of the WebRenderScrollData structure is that the per-layer
structures form a tree with a single root node. When we build the data
structure from the display list, we are generating (for now) a flat
list. Therefore we need to synthesize a root node in order to make stuff
work as intended.
MozReview-Commit-ID: IDXyziBO7pk
--HG--
extra : rebase_source : 99486a4c5b5e9938c4b7bbaa3f710d25e73d4401
Until now WebRenderScrollData was only used with "layers" WR
transactions, but we want to use it with layers-free transactions as
well. As such, we need to allow collecting information from display items
instead of layers. This restructures the code a little bit to allow
that. This patch should not have any functional effect on the "layers"
codepath, but on the "layers-free" codepath it is now actually
populating some rudimentary data into the WebRenderScrollData before
sending it across. This will be fleshed out in future patches.
MozReview-Commit-ID: BROqpsHPRND
--HG--
extra : rebase_source : 8510c52895e6be5cb546b42b02d56ec067de0623
This test (plus a couple others) were imported from upstream before they
were fully baked.
MozReview-Commit-ID: GDiFsZ8g229
--HG--
extra : rebase_source : 90e514fe100f7de89da0d34afe96262b6880838e
This test (plus a couple others) were imported from upstream before they
were fully baked.
MozReview-Commit-ID: 7pi5DBZkPVs
--HG--
extra : rebase_source : a326b4560152a21f47561b5a2e87cdf491fafe58
This fixes a regression with apz.frame_delay.enabled=true introduced in
bug 1375949.
MozReview-Commit-ID: AIcGA7c2Co0
--HG--
extra : rebase_source : b118a97674cadef1359e7658539e4e0e9cb785b8
Mike Hommey
Mike Conley
Kearwood "Kip" Gilbert
Gijs Kruitbosch
Dan Mosedale ext:(%3E)
Julian Descottes
Alexandre Poirot
Brian Grinstead
Ralph Giles
Boris Zbarsky
Daniel Holbert
Alex Gaynor
Tom Prince
Kartikaya Gupta
Nazım Can Altınova
Robert Helmer
Michael Froman
Dustin J. Mitchell
Botond Ballo