With bug 1344748 landed the default preferences and their handling has been
changed. Builds starting with Firefox 54.0 can handle that, but previous
releases don't enable Marionette at all after a restart under special
conditions (invalidating 'update.status' file before the restart).
To prevent the bustage we have to keep the preference
'marionette.defaultPrefs.enabled' around until the next ESR release
is out.
MozReview-Commit-ID: AB3liJlb6M7
--HG--
extra : amend_source : 35ae31af3c1a44d9ad965dbeb395297a73e86a81
This fixes a JS exception that gets thrown when one tries to capture a profile
in this case.
--HG--
extra : rebase_source : 46f6eeed3c17086b0b6c35b26f3c9e4841dd6cff
IMEContentObserver notifies IME of 3 notifications at most when editor is changed.
The order is:
1. text change (with merged range if 2 or more change occurred during an edit transaction)
2. selection change (only the latest selection change. other changes occurred before that during an editor transaction are ignored)
3. position change (scrolled, resized, window moved, etc)
This does not check the behavior in designMode because some operation in testWithHTMLEditor() causes unexpected behavior, e.g., moving focus. It *might* be bug of design mode. However, it doesn't matter for this bug. The important thing of this bug is, there should be automated tests for IMEContentObserver. And fortunately, IMEContentObserver does not check the type of editor. So, it's enough to test only contenteditable element for HTMLEditor at least for now. Therefore, I gave up to test it in designMode for now.
MozReview-Commit-ID: 7L6ZlbVMU2P
--HG--
extra : rebase_source : 8282fe7aa2f4d405f2576f05d46b60b044223855
For testing IMEContentObserver, text change, selection change and position change notifications should be exposed to JS with nsITextInputProcessorNotification.
MozReview-Commit-ID: 3PUhKXRwnAn
--HG--
extra : rebase_source : fce7a73683a2d4811070453629ef48d3ad15c8c8
IMEContentObserver can store pointer of IMENotificationRequests of its mWidget. Therefore, it can check the requests dynamically when it receives content change or layout change.
This patch makes IMEContentObserver stores IMENotificationRequests as pointer and check it at every change notification received. Additionally, notification request may be changed due to focus move or something. Therefore, this patch makes IMEContentObserver and IMEContentObserver::IMENotificationSender() check if the notifications are still necessary.
MozReview-Commit-ID: 2uU2wN15D8v
--HG--
extra : rebase_source : 6086e0293343632df43087c767ad00521e764476
IMEContentObserver may need to change notifications to send when TextInputProcessor begins input transaction. In current design, IMEContentObserver needs to retrieve IMENotificationRequests at every change. However, if nsIWidget returns a reference to its IMENotificationRequests, IMEContentObserver can call it only once.
For that purpose, this patch changes nsIWidget::GetIMENotificationRequests() to nsIWidget::IMENotificationRequestsRef() and make it return |const IMENotificationRequests&|. However, if the lifetime of the instance of IMENotificationRequest is shorter than the widget instance's, it's dangerous. Therefore, it always returns TextEventDispatcher::mIMENotificationRequests. TextEventDispatcher's lifetime is longer than the widget. Therefore, this guarantees the lifetime.
On the other hand, widget needs to update TextEventDispatcher::mIMENotificationRequests before calls of nsIWidget::IMENotificationRequestsRef(). Therefore, this patch makes TextEventDispatcher update proper IMENotificationRequests when it gets focus or starts new input transaction and clear mIMENotificationRequests when it loses focus.
Note that TextEventDispatcher gets proper requests both from native text event dispatcher listener (typically, implemented by native IME handler class) and TextInputProcessor when TextInputProcessor has input transaction because even if TextInputProcessor overrides native IME, native IME still needs to know the content changes since they may get new input transaction after that.
However, there may not be native IME handler in content process. If it runs in Android, PuppetWidget may have native IME handler because widget directly handles IME in e10s mode for Android. Otherwise, native IME handler is in its parent process. So, if TextInputHandler has input transaction in content process, PuppetWidget needs to behave as native event handler. Therefore, this patch makes PuppetWidget inherit TextEventDispatcherListener and implements PuppetWidget::IMENotificationRequestsRef().
MozReview-Commit-ID: 2SW3moONTOX
--HG--
extra : rebase_source : d2634ada6c33dbf7a966fadb68608411ee24bfab
The new Reps bundle from Bug 1357341 is all about functions now,
so we should remove all unnecessary `createFactory` calls
we used to do when creating Reps.
MozReview-Commit-ID: 4KvCThhwphv
--HG--
extra : rebase_source : ade723dbdb78752e5535f18b20370b6c46a54c48
This is a temporary workaround to avoid the intermittent orange. We still need to track down what the
underlying cause of the difference in timings between compartments and processes really is.
MozReview-Commit-ID: GmT67UDuTqN
--HG--
extra : rebase_source : 6de502e791829a11fe15c837e9dc42c649e57a90
The decay time in optimize builds could be very small, and due to timers resolution it could
end up being 0.
MozReview-Commit-ID: 3F8sm5Fmuri
--HG--
extra : rebase_source : 70a4490f50e86cd98b4f8dba632d06408c96827a
<!-- Please describe your changes on the following line: -->
In #16553 I did innocently add a support for @-moz-keyframes but as @SimonSapin pointed out, servo does not need to support -moz prefix one.
Whereas, I think servo should support @-webkit-keyframes since it is described in web
compatibility [1].
[1] https://compat.spec.whatwg.org/#css-at-rules
---
<!-- 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: f51170a2a10691a1ad0b5da1b0c6e14e5186b8ba
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d1cbd51dd242d96a22182e202488374b286a6bb4
This patch removes the Marionette server's ability to accept non-loopback
connections completely. The configuration option for this, the
marionette.forcelocal preference, was removed in the previous patch in
this changeset.
MozReview-Commit-ID: 3XXYpTDGs8S
--HG--
extra : rebase_source : a5ffaab36734afe1ca663453b21e5fd6f90ac970
marionette.forcelocal was historically used to connect free-standing B2G
devices over real networks, such as wi-fi, to Marionette. Since we do
not have this use case anymore and Android uses adb and port forwarding,
this removes the marionette.forcelocal preference to reduce the attack
surface for Marionette.
MozReview-Commit-ID: KgqUrilpwMM
--HG--
extra : rebase_source : 43cbb0e3928f3c2a383d66ec30873953a45beda5
We will cache all preferences which will be read during classifing channel
- Store them into static variables nsUrlClassifierDBService
- Use a singleton class to manage/update preferrences in nsChannelClassifier
MozReview-Commit-ID: GvyBI3rVpYh
--HG--
extra : rebase_source : 0cec0724bd47f55c7b1666e700d172698a708efb
Change the ExperimentsService to get the current value of the preferences (since it only uses them once or twice), so that they match the values in Experiments, and avoid differences causing promises to be rejected in the updateManifest call.
Also fix Experiments to correctly re-enable itself when toolkit.telemetry.enabled is changed from false to true (also fixes bug 1232648).
Finally, add a catch for a promise when calling updateManifest so that we don't get an uncaught promise exception.
MozReview-Commit-ID: GD6gfcRSgbx
--HG--
extra : rebase_source : a5045275c2f864b75443c2cb8fc531ea0e84a704
