9ae60e8e7b9f37299ca1be4f3558f0cea18d13cd: servo: Merge #20265 - Fix JS object conversion in unions (from Xanewok:fix-js-objects-in-unions); r=jdm
Igor Matuszewski <Xanewok@gmail.com> - Wed, 14 Mar 2018 12:04:23 -0400 - rev 408154
Push 61131 by servo-vcs-sync@mozilla.com at Wed, 14 Mar 2018 17:26:37 +0000
servo: Merge #20265 - Fix JS object conversion in unions (from Xanewok:fix-js-objects-in-unions); r=jdm <!-- Please describe your changes on the following line: --> Requires safe `Heap::boxed` constructor from https://github.com/servo/rust-mozjs/pull/395 (more info on it is in the PR). Since unions currently assume that their respective members root themselves and can be stored on heap, I modified the union member object conversion branch to convert to a `RootedTraceableBox<Heap<*mut JSObject>>` (which is the currently generated type for objects in said unions). I did it only for Unions and not dictionaries, since some dictionaries had bare `*mut JSObject` members - is this a mistake and something that needs further fixing? Does this need a test, e.g. passing a union with object to a function that returns said object, and comparing the results for equality? r? @jdm Generated code with this patch (for `StringOrObject`): ```rust impl FromJSValConvertible for StringOrObject { type Config = (); unsafe fn from_jsval(cx: *mut JSContext, value: HandleValue, _option: ()) -> Result<ConversionResult<StringOrObject>, ()> { if value.get().is_object() { match StringOrObject::TryConvertToObject(cx, value) { Err(_) => return Err(()), Ok(Some(value)) => return Ok(ConversionResult::Success(StringOrObject::Object(value))), Ok(None) => (), } } // (...) } } impl StringOrObject { // (...) unsafe fn TryConvertToObject(cx: *mut JSContext, value: HandleValue) -> Result<Option<RootedTraceableBox<Heap<*mut JSObject>>>, ()> { Ok(Some(RootedTraceableBox::from_box(Heap::boxed(value.get().to_object())))) } } ``` --- <!-- 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 - [ ] These changes fix #17011 (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: e597cd9e1adc23ae30587ff6bffc05119ac33fb9
51b5d10855c9cce20abf96df79e91dc4176bb5bb: Bug 1445350 - fix browser_panelUINotifications_multiWindow.js so it doesn't fail on win10, r=dthayer
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Wed, 14 Mar 2018 13:18:35 +0000 - rev 408153
Push 61130 by gijskruitbosch@gmail.com at Wed, 14 Mar 2018 17:26:17 +0000
Bug 1445350 - fix browser_panelUINotifications_multiWindow.js so it doesn't fail on win10, r=dthayer MozReview-Commit-ID: Jk3ah2Xtr58
3a7a26b914ac50499ac4781e4ce6ce4fe3efbb3c: Bug 1444823 - Execute messageManager.sendAsyncMessage after runTest; r=jdescottes.
Nicolas Chevobbe <nchevobbe@mozilla.com> - Wed, 14 Mar 2018 09:54:17 +0100 - rev 408152
Push 61129 by nchevobbe@mozilla.com at Wed, 14 Mar 2018 17:20:11 +0000
Bug 1444823 - Execute messageManager.sendAsyncMessage after runTest; r=jdescottes. MozReview-Commit-ID: Ansa6okYRg
4c204ccf3a7c511ce2cb33aec90dfbab0b3f082f: Bug 1445080 - fix handling of remote web progress for non-tab browsers, r=Gijs,mconley
Shane Caraveo <scaraveo@mozilla.com> - Wed, 14 Mar 2018 09:12:26 -0500 - rev 408151
Push 61128 by mixedpuppy@gmail.com at Wed, 14 Mar 2018 16:59:01 +0000
Bug 1445080 - fix handling of remote web progress for non-tab browsers, r=Gijs,mconley Ensure remoteWebProgress is initialized for remote browsers. Includes devtools fix from jryans. MozReview-Commit-ID: Ce3TzwkNnyi
8e53f08e1d90e1036b75868a459addea99108c69: Bug 1437532 - prevent doing memset on a non-trivial type. r=jorendorff
Andi-Bogdan Postelnicu <bpostelnicu@mozilla.com> - Tue, 13 Mar 2018 11:57:49 +0200 - rev 408150
Push 61127 by bpostelnicu@mozilla.com at Wed, 14 Mar 2018 16:44:24 +0000
Bug 1437532 - prevent doing memset on a non-trivial type. r=jorendorff MozReview-Commit-ID: C8BfwJSHkWM
73c5eb0fb23f62edd9e84f68ea8bb54e79716f17: Backed out 2 changesets (bug 1310295) for Mochitest and TV failures on browser/components/places/tests/browser/browser_bookmark_folder_moveability.js
Dorel Luca <dluca@mozilla.com> - Wed, 14 Mar 2018 18:23:46 +0200 - rev 408149
Push 61126 by dluca@mozilla.com at Wed, 14 Mar 2018 16:25:05 +0000
Backed out 2 changesets (bug 1310295) for Mochitest and TV failures on browser/components/places/tests/browser/browser_bookmark_folder_moveability.js Backed out changeset a277657bfffa (bug 1310295) Backed out changeset b1af75c617ea (bug 1310295)
11c1e1afaaca3d57923f7cafd71e7f64a8de4146: Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 09 Mar 2018 12:39:40 +0900 - rev 408148
Push 61125 by masayuki@d-toybox.com at Wed, 14 Mar 2018 16:23:52 +0000
Bug 1443421 - part 2: IMContextWrapper should dispatch eKeyDown or eKeyUp event as "processed by IME" even when IM sent some signals without sending key event again r=m_kato ibus and fcitx usually post key event to other IME process, then, if it causes some signals to updating composition string, they may not send the posted key event to us again. Then, IMContextWrapper dispatches neither eKeyDown nor eKeyUp event since mProcessingKeyEvent becomes non-nullptr only while OnKeyEvent() is called. So, IMContextWrapper need to store key event if OnKeyEvent() assumes that given key event is posted to different process. Then, if IMContextWrapper receives some signals, it should dispatch eKeyDown and eKeyUp event with stored key event. Note that we cannot compare the pointer of first event and following event directly even though usually both events are same address as far as I checked because according to the source code of ibus, fcitx and GDK, they use gdk_event_copy() to keep storing original event. According to the document of the API, it might just increment refcount. However, the actual implementation of the API always creates another instance and return it. So, it might be used same address by arena allocation or something accidentally. Anyway, we shouldn't compare them. Instead, we need to compare each information of two key events. Unfortunately, we also cannot compare them simply. Both ibus and fcitx set unused bits of GdkEventKey::state to true when they send back the event to us. Therefore, we should compare some of or all of the members by ourselves. I think that matching time must be enough in most cases since its value of native key events are properly set. However, for safer code, this patch also checks type, keyval and part of state. MozReview-Commit-ID: FZSwN61v0Sd
b93dcde52457de2984d637ca45d313d34640ed52: Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato
Masayuki Nakano <masayuki@d-toybox.com> - Fri, 09 Mar 2018 00:46:52 +0900 - rev 408147
Push 61125 by masayuki@d-toybox.com at Wed, 14 Mar 2018 16:23:52 +0000
Bug 1443421 - part 1: Make IMContextWrapper not dispatch eKeyDown and eKeyUp event if the native key event is being handled by other IME process r=m_kato ibus and fcitx have asynchronous key event handling mode and it's enabled in default settings. That is, when they receive a key event from application via a call of gtk_im_context_filter_keypress(), they may post the key event information to other IME process, then does nothing but store the copy of the event with gdk_event_copy() and returns true for the result of gtk_im_context_filter_keypress(). When the other IME process handles the event, returns the result to them in our process. Then, they send the stored key event to us again. Finally, they actually handles the event in our process actually. Therefore, we may receive every key event twice. So, this causes dispatching eKeyDown event and eKeyUp event twice. Preceding key event is always marked as "processed by IME" since gtk_im_context_filter_keypress() returns true temporarily and following key event is dispatched as expected. So, we need to ignore the first event only when gtk_im_context_filter_keypress() returns true but the event is posted to different process. Unfortunately, we cannot know if the key event is actually posted to different process directly. However, we can know if active IM is ibus, fcitx or another one and if ibus or fcitx is in asynchronous key handling mode. The former information is provided by gtk_im_multicontext_get_context_id(). It returns a string which is set to the IM multicontext instance by creator. We'll get "ibus" if IM is ibus, get "fcitx" if IM is fcitx. The latter information is not provided. However, they consider the mode from env value. ibus checks IBUS_ENABLE_SYNC_MODE. fcitx checks both IBUS_ENABLE_SYNC_MODE and FCITX_ENABLE_SYNC_MODE. Additionally, we can know if received key event has already been posted to other IME process. They use undefined bit of GdkEventKey::state to store if the key event has already been posted (1 << 25, they called "ignored" flag). Although their approach is really hacky but we can refer the information at least for now. Finally, when we guess a key event is posted to other IME process, let's IMContextWrapper::OnKeyEvent() not dispatch eKeyDown nor eKeyUp event. Note that if it's handled synchronously as unexpected, it may causes dispatching one or more composition events and/or delete content event. So, in such case, we dispatch a keyboard event for processing key event anyway. There is only once case we'll fail to dispatch keyboard event. If we receive signals to dispatch composition events or delete content command event when IM receives the result from other IME process but it doesn't send the key event to us. This will be fixed by the following patch. MozReview-Commit-ID: 94PrlnmQ3uJ
22f4a3eab7195519de3c93e2673dd32630646e83: Bug 1435788 - Allow handling focus-changing events prior to the first update on GPU process restart. r=rhunt
Kartikaya Gupta <kgupta@mozilla.com> - Wed, 14 Mar 2018 08:43:56 -0400 - rev 408146
Push 61124 by kgupta@mozilla.com at Wed, 14 Mar 2018 16:00:34 +0000
Bug 1435788 - Allow handling focus-changing events prior to the first update on GPU process restart. r=rhunt If the GPU process restarts, the mLastAPZProcessedEvent gets reset to 1. The code in Update() checks for this special case and resets the value to the incoming content process sequence number. However, we before that first call to Update() on the sampler thread, the FocusState might get calls to ReceiveFocusChangingEvent(), which would be triggered by input events on the controller thread. These input events would advance mLastAPZProcessedEvent which would bypass the special case handling in Update(). This can leave mLastAPZProcessedEvent at a lower value than mLastContentProcessedEvent which triggers assertion failures. This patch ensures that calls to ReceiveFocusChangingEvent() during this initial state doesn't increment mLastAPZProcessedEvent, and so allows the special case handling in Update() to work as expected. It also adds the special case handling to the branch where the first Update() call results in no focus target being selected. MozReview-Commit-ID: 7P2O2qg0mXj
bfaff9e255ef859f83445c4e46504f1590c7b7f8: servo: Merge #20243 - style: add infrastructure to match the :host selector (from emilio:host-selector-on-the-way); r=SimonSapin
Emilio Cobos Álvarez <emilio@crisal.io> - Wed, 14 Mar 2018 10:38:45 -0400 - rev 408145
Push 61123 by servo-vcs-sync@mozilla.com at Wed, 14 Mar 2018 15:56:25 +0000
servo: Merge #20243 - style: add infrastructure to match the :host selector (from emilio:host-selector-on-the-way); r=SimonSapin Source-Repo: https://github.com/servo/servo Source-Revision: 148beb4ea5f8f1680e694ac48045a632da58269c
4c417b678b5d8337879cbc5929bb16ef85093da0: Bug 1445403 - Add thread assertions as documentation. r=rhunt
Kartikaya Gupta <kgupta@mozilla.com> - Wed, 14 Mar 2018 08:42:44 -0400 - rev 408144
Push 61122 by kgupta@mozilla.com at Wed, 14 Mar 2018 15:51:15 +0000
Bug 1445403 - Add thread assertions as documentation. r=rhunt MozReview-Commit-ID: DmOnjBymf8G
76ecb95e795f648a4fc0da40db785911f55881a2: Bug 1445403 - Sprinkle some magical Mutex dust on FocusState. r=rhunt
Kartikaya Gupta <kgupta@mozilla.com> - Wed, 14 Mar 2018 08:42:44 -0400 - rev 408143
Push 61122 by kgupta@mozilla.com at Wed, 14 Mar 2018 15:51:15 +0000
Bug 1445403 - Sprinkle some magical Mutex dust on FocusState. r=rhunt MozReview-Commit-ID: D9Dd9Fm2JTY
d2252a25471271ce473936fcfd6c689f9bce3273: Bug 1445403 - Move FocusState method implementations into .cpp file. r=rhunt
Kartikaya Gupta <kgupta@mozilla.com> - Wed, 14 Mar 2018 08:42:44 -0400 - rev 408142
Push 61122 by kgupta@mozilla.com at Wed, 14 Mar 2018 15:51:15 +0000
Bug 1445403 - Move FocusState method implementations into .cpp file. r=rhunt MozReview-Commit-ID: FycCdfjdEWK
7a4f85c76c7c955ca581fafee0a47f9e082b2594: Bug 1444327 - Bring back ability to copy font URL by adding context menu; r=jdescottes
Patrick Brosset <pbrosset@mozilla.com> - Wed, 14 Mar 2018 16:16:55 +0100 - rev 408141
Push 61121 by pbrosset@mozilla.com at Wed, 14 Mar 2018 15:34:55 +0000
Bug 1444327 - Bring back ability to copy font URL by adding context menu; r=jdescottes In the fonts panel UI prior to Firefox 60, remote font URLs used to be displayed in full in a text input field. It made it easy to copy them. With the redesign that happened in 60 (bug 1437548 and 1442001), getting the URL became harder. The URL isn't visible anymore easily. There's a link that can be clicked to load the URL in the browser, or it can also be copied from the @font-face CSS rule code section. But that's harder. This change adds a simple right-click context menu to the link that has one item only: copy link. MozReview-Commit-ID: 2oSMoWKYhTk
391be7bb77bcc502cb297dacc8f70dc3ac6019de: Bug 1445419 - Makes AsyncPanZoomController::CanScroll distinguish between wheel scrolling and non-wheel scrolling r=kats
Zhang Junzhi <zjz@zjz.name> - Wed, 14 Mar 2018 04:14:13 +0800 - rev 408140
Push 61120 by kgupta@mozilla.com at Wed, 14 Mar 2018 15:24:29 +0000
Bug 1445419 - Makes AsyncPanZoomController::CanScroll distinguish between wheel scrolling and non-wheel scrolling r=kats Scrollable doesn't mean exactly the same thing as wheel-scrollable. However, AsyncPanZoomController::CanScroll(const InputData& aEvent) mistakenly calls CanScrollWithWheel without distinguishing between wheel scrolling and non-wheel scrolling, which may potentially lead to wrong APZC targets during the hittesting stage. MozReview-Commit-ID: 6xXQdtObLwB
0f1a064cc4d7a320e52d6c2ad9ab0a4bdc378b09: Backed out changeset a88235c19594 (bug 1444327) for ESlint failure at devtools/client/inspector/fonts/test/browser_fontinspector_copy-URL.js
Coroiu Cristina <ccoroiu@mozilla.com> - Wed, 14 Mar 2018 17:01:11 +0200 - rev 408139
Push 61119 by ccoroiu@mozilla.com at Wed, 14 Mar 2018 15:01:32 +0000
Backed out changeset a88235c19594 (bug 1444327) for ESlint failure at devtools/client/inspector/fonts/test/browser_fontinspector_copy-URL.js
a277657bfffad2c7bd6bb1f1782eb32c79596ec3: Bug 1310295 - Provide a Places database migration routine to remove non-built-in roots. r=mak
Mark Banner <standard8@mozilla.com> - Fri, 02 Mar 2018 11:09:12 +0000 - rev 408138
Push 61118 by mbanner@mozilla.com at Wed, 14 Mar 2018 14:57:45 +0000
Bug 1310295 - Provide a Places database migration routine to remove non-built-in roots. r=mak MozReview-Commit-ID: G2vdW3PRlqo
b1af75c617eafc84cd87c1e0ac94fb26929c56bf: Bug 1310295 - Make left pane queries virtual in the Places Library window. r=kitcambridge,mak
Mark Banner <standard8@mozilla.com> - Fri, 16 Feb 2018 20:30:04 +0000 - rev 408137
Push 61118 by mbanner@mozilla.com at Wed, 14 Mar 2018 14:57:45 +0000
Bug 1310295 - Make left pane queries virtual in the Places Library window. r=kitcambridge,mak MozReview-Commit-ID: DcEMAlrXu8R
a88235c19594b34b1f7f3b2022f89b35fe1f21bf: Bug 1444327 - Bring back ability to copy font URL by adding context menu; r=jdescottes
Patrick Brosset <pbrosset@mozilla.com> - Mon, 12 Mar 2018 14:49:14 +0100 - rev 408136
Push 61117 by pbrosset@mozilla.com at Wed, 14 Mar 2018 14:45:28 +0000
Bug 1444327 - Bring back ability to copy font URL by adding context menu; r=jdescottes In the fonts panel UI prior to Firefox 60, remote font URLs used to be displayed in full in a text input field. It made it easy to copy them. With the redesign that happened in 60 (bug 1437548 and 1442001), getting the URL became harder. The URL isn't visible anymore easily. There's a link that can be clicked to load the URL in the browser, or it can also be copied from the @font-face CSS rule code section. But that's harder. This change adds a simple right-click context menu to the link that has one item only: copy link. MozReview-Commit-ID: 2oSMoWKYhTk
9ddcc7fdda30b289a0ef9592151293e006b024ab: servo: Merge #20294 - Update WR (port blurs and blits to brush_image) (from glennw:update-wr-blend-brush); r=jdm
Glenn Watson <github@intuitionlibrary.com> - Wed, 14 Mar 2018 08:52:20 -0400 - rev 408135
Push 61116 by servo-vcs-sync@mozilla.com at Wed, 14 Mar 2018 13:44:56 +0000
servo: Merge #20294 - Update WR (port blurs and blits to brush_image) (from glennw:update-wr-blend-brush); r=jdm Source-Repo: https://github.com/servo/servo Source-Revision: daaee046b3a5a949a22b69a7ba42d2d741914645
(0) -300000 -100000 -30000 -10000 -3000 -1000 -300 -100 -50 -20 +20 +50 +100 +300 +1000 +3000 +10000 +30000 +100000 tip