This is not 100% reliable, but it seems to have enough time to run
helper.exe before Default Apps Settings page scans the registry.
And I don't think we should make `LaunchHelper` synchromous just for
this unusual (zip build) case, especially when the fallback (top of
Default Apps) is good enough.
Differential Revision: https://phabricator.services.mozilla.com/D180533
The associated comment says to set this value to debug when developing to get
more logging, but it appears it was accidentally left set to debug when
committing.
Differential Revision: https://phabricator.services.mozilla.com/D172291
This also fixes a bug in ASRouter devtools that prevented evaluation of
expressions containing nested promises. Objects containing promises are now
correctly serialized to the ASRouter devtools and expressions evaluate
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D169408
This also fixes a bug in ASRouter devtools that prevented evaluation of
expressions containing nested promises. Objects containing promises are now
correctly serialized to the ASRouter devtools and expressions evaluate
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D169408
This also fixes a bug in ASRouter devtools that prevented evaluation of
expressions containing nested promises. Objects containing promises are now
correctly serialized to the ASRouter devtools and expressions evaluate
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D169408
There are 3 types of changes in this commit:
- from `loadURI(foo.spec)` to `loadURI(foo)`, as there's already a URI
- from `loadURI("string")` to `loadURI(Services.io.newURI("string"))` as the URL is hardcoded
- one or two where there is perhaps an intermediate variable but the patch
context should still make it trivial to ascertain the change is correct.
Depends on D168393
Differential Revision: https://phabricator.services.mozilla.com/D168394
There are 3 types of changes in this commit:
- from `loadURI(foo.spec)` to `loadURI(foo)`, as there's already a URI
- from `loadURI("string")` to `loadURI(Services.io.newURI("string"))` as the URL is hardcoded
- one or two where there is perhaps an intermediate variable but the patch
context should still make it trivial to ascertain the change is correct.
Depends on D168393
Differential Revision: https://phabricator.services.mozilla.com/D168394
Gfx blocklist doesn't actually use the desktop environment filter so
remove that functionality. We can reintroduce it in the future if we
need it.
Differential Revision: https://phabricator.services.mozilla.com/D166090
I was unable to get gnome searching working at all on my machine (perhaps it's broken on Ubuntu?), thus I was unable to verify this fix myself -- but it seems pretty straightforward and safe to take.
Differential Revision: https://phabricator.services.mozilla.com/D164902
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
Bug 1805414 will move menu event handling to the DOM.
With that change the current synthetic click behavior of XUL menuitems
breaks. On current central, we rely on nsMenuFrame::HandleEvent not
getting called at all for synthetic clicks, and instead we just fire a
command event synchronously here:
https://searchfox.org/mozilla-central/rev/a0d4f8f112c5c792ae272bf6ce50763ddd23ffa2/dom/xul/nsXULElement.cpp#1071
After my patch the command event is fired properly (potentially
asynchronously too) by the regular menu activation machinery, which is
preferable.
* They fire a command event synchronously (even though on some
platforms like macOS activating a context menu item is async).
* They use a totally different codepath from what a user does.
* They don't deal with native menus, etc.
We have a proper API for this (activateItem) which takes a much more
closer codepath to what users do, requires that the menu is shown, etc.
Use that API instead for testing.
As a benefit, tests now do not need to close the context menu manually
when clicking on a menu item (because we trigger the same code path as
users clicking the menu).
Differential Revision: https://phabricator.services.mozilla.com/D164567
