We currently don't generate a ::ToJSON() method for WebIDL types with record<K,V>
members. These types should be safe to convert to JSON, as long as type V itself
is. Per spec, type K is always a DOMString, USVString, or ByteString.
There are two other means from which a caller can get the current state
which originally ignored validation -- GetImageStatus and
StartDecodingWithResult. These methods are used by layout in some
circumstances to decide whether or not the image is ready to display. As
observed in some web platform tests, in particular
css/css-backgrounds-3/background-size-031.html, we may actually validate
and purge the cache for images under test. The state given by the
aforementioned methods was misleading, because validation changed it.
Now they take into account validation, and do not imply any particular
state while validation is in progress.
IProgressObserver::SetNotificationsDeferred is now used just for
ProgressTracker to track when there is a pending notification for
an observer. It has been renamed to MarkPendingNotify and
ClearPendingNotify to make a clear distinction.
When cache validation is in progress, imgRequestProxy defers its
notifications to its listener until the validation is complete. This is
because the cache may be discarded, and the current state will change.
It attempted to share the same flags with notification deferrals used by
ProgressTracker to indicate that there is a pending notification, but
this has problematic/confusing. Hence this patch creates dedicated flags
for notification deferrals due to cache validation.
When --jsdebugger is passed to geckodriver, it will override
preferences related to starting the Browser Toolbox and pass
-jsdebugger on to the Firefox process.
It is functionally equivalent to "./mach marionette test --jsdebugger".
MozReview-Commit-ID: ADfrLPXtQoy
Followup to #19966 because, well...
The animation code should probably be more obvious.
Source-Repo: https://github.com/servo/servo
Source-Revision: cf4f89c36e4cd62b8833cfc968ccac055fb091dd
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 97810b3daf65ef973d474c8fa1786e35342f8c2c
Summary:
These are made persistent:
1. What questions will you answer with this data?
These probes are critical to understanding use of notifications and push in
general (push provides significant incentive to sites to use notifications, so
the two are highly correlated). These probes allow us to understand when push
is enabled, and when pushes are propagated.
2. Why does Mozilla need to answer these questions? Are there benefits for users? Do we need this information to address product or business requirements? Some example responses:
These allow is to understand baseline platform characteristics and ensure that changes don't degrade experience.
3. What alternative methods did you consider to answer these questions? Why were they not sufficient?
We have telemetry on autopush (our server infrastructure), and the information we get there is in many ways superior to data collected through the browser, but these metrics are impossible to measure using autopush.
4. Can current instrumentation answer these questions?
See 3.
5. List all proposed measurements and indicate the category of data collection for each measurement, using the Firefox data collection categories on the found on the Mozilla wiki.
Measurement Description Data Collection Category Tracking Bug #
WEB_NOTIFICATION_CLICKED 2 1429286
WEB_NOTIFICATION_PERMISSIONS 2 1429286
WEB_NOTIFICATION_SHOWN 2 1429286
PUSH_API_NOTIFY 2 1429286
6. How long will this data be collected? Choose one of the following:
I want to permanently monitor this data. (Martin Thomson, :mt)
7. What populations will you measure?
All channels, countries, and locales. No filtering is in place. These are all opt-out telemetry.
8. Please provide a general description of how you will analyze this data.
Changes are monitored for changes, or analyzed on demand.
I believe that there are telemetry alerts that trigger on significant changes. If there isn't, there should be.
9. Where do you intend to share the results of your analysis?
telemetry.m.o, w3c webapps
Bug #: 1429286
Differential Revision: https://phabricator.services.mozilla.com/D361
MozReview-Commit-ID: Kkc1Qr6UaJ8
The changes in bug 1324883 regressed YouTube, so back them out.
The changes in bug 1324883 were trying to cause the media cache to be cleared
on tab close and on CTRL+F5 reload (i.e. a bypass cache-reload) but they are
causing problems on YouTube, which doesn't use the media cache and instead
uses MSE.
MozReview-Commit-ID: Hx2cehZ2wm1
--HG--
extra : rebase_source : fa0bd85570746e60341e8e2d3f874f9bd30c0232
It's a hack, should die.
Source-Repo: https://github.com/servo/servo
Source-Revision: dc446198a733cab3416aaccdd13bf6e86ffeb294
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0cfb968e80c9f19f5c4dfad8187f597edc26e344
This patch rearranges these functions so that nsPrefBranch::GetPrefType() calls
into Preferences::GetType(), because all other nsPrefBranch methods depend on
Preferences methods.
The patch also removes the `aKind` argument from GetType(), because it has no
effect -- a pref only has one type, regardless of whether it has a default
value, a user value, or both.
MozReview-Commit-ID: J3vxFPaP8S3
The list of sites to suppress flash infobars on should not be
downloaded from shavar unless the infobar feature is enabled.
MozReview-Commit-ID: BjkS5vWiilg
--HG--
extra : rebase_source : ba7c104b758fc04994b8438222dda0c7feadc787
<!-- Please describe your changes on the following line: -->
r? emilio
---
<!-- 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 build-geckolib` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19936 (github issue number if applicable).
<!-- Either: -->
- [x] These changes do not require tests
<!-- 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: 804b4b3db6d75d35b2f2ec8acf83207c5875aa74
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 98289c90b219ab15a6fee871ae47f6c7af252371
In some cases there are imported tests where the same test is compared against
two reference pages, once as == and once as !=. Webrender is currently failing
the == tests but not the != tests. However there is no way to annotate this
precisely in the failures.list file, so we had previously marked the tests
as random-if. This patch modifies the import-tests.py to recognize a ref:<file>
argument in failures.list to match the reference file as well, and uses it to
clarify the webrender reftest expectations.
MozReview-Commit-ID: 6nAXoCQDreI
--HG--
extra : rebase_source : 93633ed6f62ccfb4b28ebed34943781350c4c831
This makes us consistent with the old style system and Blink / WebKit.
Not adding a test because shorthands serialization is a mess... :(
Anyway, nothing like fixing bugs by removing code.
Bug: 1436031
Source-Repo: https://github.com/servo/servo
Source-Revision: dde15d8d6511bfb1440afeff5135757611b96a6c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9d4213440d0c137c44b626038d46d6d344370cdd
Deleting lines in part 1 caused two tests to break, because they check
the line numbers for source files. The devtools part of the patch was
automatically generated.
MozReview-Commit-ID: DrDZeyVnpE0
--HG--
extra : rebase_source : 72c1623015f029a5adef20669cc102c568d3b67e
MozReview-Commit-ID: 270iURVhNRu
This patch builds upon the existing DLL services functionality:
1) We add code to obtain the name of the subject from the cert used to sign a
binary (if present). This code is added inside mozglue because in the future
we will be using this code from the DLL blocklist, which is also located
there.
2) We add annotation functionality that registers itself for DLL load events
and updates crash reporter annotations as new libraries are loaded. It also
annotates any existing libraries that are also in memory at the time that the
CertAnnotator is first instantiated. This all happens off main thread, with
the exception of actually making the annotation when in a child process.
--HG--
extra : rebase_source : f86c1a6fd2a44f21a71e7a7418267b3b0d5feeec
Also, remove a now-obsolete comment from placesOverlay.xul and remove
some now-empty XPCShell test head files.
MozReview-Commit-ID: 6kKVQu8FAL3
--HG--
extra : rebase_source : 7dd05818d68a15bd170af734078db4ba45029d80
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b