This starts using the same spacing as commonDialog for these dialogs
with proton enabled. It also updates the checkbox spacing, alignment
and colour (bug 1705882 will fix the correct colour choice here.)
The spacing is still not ideal in the second dialog (after you click
'Choose Application') but there isn't much we can do about that unless
we get rid of the confirmation text about where to change the preference,
or we start creating ways for the dialog to tell SubDialog to resize
it when items are added/removed, which is not straightforward, so I
decided not to tackle that here.
Differential Revision: https://phabricator.services.mozilla.com/D112788
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
The naming scheme references the hashchange event. This is required by the
extensions framework to call the appropriate navigation listeners when only
the reference fragment is updated by a navigation.
Differential Revision: https://phabricator.services.mozilla.com/D108725
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
I am not conviced that we have all the correct MIME types and extensions here.
It also extremely hard to figure out what the correct information is.
We should drop this.
Differential Revision: https://phabricator.services.mozilla.com/D105358
This passes around the "are we external" bit of load information a bunch,
such that the external protocol handling code has access to it.
In this bug and bug 1667468, I think ideally I would have used a check
if we're the OS default for a given protocol before continuing. However,
this information is currently unavailable on Linux (bug 1599713), and
worse, I believe is likely to remain unavailable in flatpak and other
such restricted environments (cf. bug 1618094 - we aren't able to find
out anything about protocol handlers from the OS).
So instead, we prompt the user if we are about to open a link passed
to us externally. There is a small chance this will be Breaking People's
Workflows, where I don't know whether anyone relies on Firefox happily
passing these URIs along to the relevant application (more convenient
than doing all the registry/API work yourself in scripts!) or anything
like that. To help with that, there's a pref,
`network.protocol-handler.prompt-from-external`, that can be created and
set to false to avoid prompting in this case.
Differential Revision: https://phabricator.services.mozilla.com/D103967
