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
The current shortcut detection was good enough for a long while -- it was mainly used for Telemetry purposes, and installer created shortcuts were almost always created anyways -- so both the rate of mismatches and the consequences of them were fairly low. This changed when we implemented Private taskbar pinning, most notably because when we're creating Private Browsing shortcuts in the installer (which we ought to do to work around various Windows bugs), we end up with 2 strings for the shortcut names (one for the installer, one for the browser).
The other thing that has changed since this was originally implemented is that all of those code has moved off of the main thread -- so it is less perf-sensitive than it was before.
With these two things in mind, making our shortcut detection much more accurate seems like the right thing to do. There's still rare cases (noted in the original comments) where it could be wrong -- but with this change we no longer rely on the file name, which can very easily be wrong for a number of reasons.
This also includes a fix for a bug I introduced in https://bugzilla.mozilla.org/show_bug.cgi?id=1789974 that caused pinning not to work if a shortcut needed to be created at pinning time (unlikely except in zip builds, but still needs to be fixed).
Differential Revision: https://phabricator.services.mozilla.com/D158799
