When screen sharing preview is generated a system dialog is fired and the same system dialog
is fired again when an actual sharing is performed.
Shared resource is selected by system dialog only, we don't have any control which system resource
will be shared over PipeWire. So there's no point to generate a preview of a resource which may not be shared
as an user can select a different resorce.
The preview should be generated by system dialog where the shared resource is selected and confirmed,
we only consume that user selection.
Depends on D96694
Differential Revision: https://phabricator.services.mozilla.com/D96806
When we share content by PipeWire, a system portal is used to select which content is shared.
In that case put only PipeWire portal name placeholder to device list.
Differential Revision: https://phabricator.services.mozilla.com/D96694
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
The browser currently only enables plugin behavior for Flash and our internal test plugins. This patch replaces support for those plugins with a simple fallback that shows a transparent region where the plugin would have been. It removes the file system search(es) for the plugin dynamic libraries and short-circuits the logic to determine if plugins should do something special -- all implementations now behave the same in the presence of plugin elements.
The new behavior is:
1. If the <object> or <embed> element lists a type of something other than "x-shockwave-flash" or "x-test" then the behavior is unchanged. This means that non-plugin types behave properly and unknown types (for example, typos) are also unaffected (they reduce to 0x0 elements).
2. If the <object> element has an HTML fallback in the DOM (see spec for <object> elements) then the fallback is always shown.
3. Otherwise, the element is shown as a transparent region with the size specified in attributes.
Differential Revision: https://phabricator.services.mozilla.com/D95902
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
This patch makes the ContextMenu to send cookieJarSettings from content
to the parent process via ContextMenuChild/Parent. The cookieJarSettings
will be used in 'Save ... As'.
Differential Revision: https://phabricator.services.mozilla.com/D95615
This patch makes the ContextMenu to send cookieJarSettings from content
to the parent process via ContextMenuChild/Parent. The cookieJarSettings
will be used in 'Save ... As'.
Differential Revision: https://phabricator.services.mozilla.com/D95615
These methods are no longer necessary, as all loads which can trigger process
switches now go through DocumentChannel.
The shouldLoadURI methods on nsIWebBrowserChrome3 are unfortunately still
necessary as they're used by the disabled-by-default "Single-Site Browser"
feature. In the future this may be possible to clean-up.
Differential Revision: https://phabricator.services.mozilla.com/D94638
Using the subscript loader is currently our best way of getting the loaded scripts recorded for entry
in the ScriptPreloader which is used to cache startup-related JavaScript within the startup window.
Originally, we were using <script> tags to load those scripts, but unfortunately, that loading mechanism
does not qualify for being noted by the ScriptPreloader.
This is a workaround until the Stencil project by the SpiderMonkey team Phase 2 is complete (see bug 1663956),
which should allow us to more easily note scripts to cache at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D95407
Using the subscript loader is currently our best way of getting the loaded scripts recorded for entry
in the ScriptPreloader which is used to cache startup-related JavaScript within the startup window.
Originally, we were using <script> tags to load those scripts, but unfortunately, that loading mechanism
does not qualify for being noted by the ScriptPreloader.
This is a workaround until the Stencil project by the SpiderMonkey team Phase 2 is complete (see bug 1663956),
which should allow us to more easily note scripts to cache at runtime.
Differential Revision: https://phabricator.services.mozilla.com/D95407
This is to prevent issues with parsing the correct hostname for displaying and adding
exceptions for urls like view-source:.
Differential Revision: https://phabricator.services.mozilla.com/D94421
This is to prevent issues with parsing the correct hostname for displaying and adding
exceptions for urls like view-source:.
Differential Revision: https://phabricator.services.mozilla.com/D94421
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
GeckoView is seemingly the last user depending on MediaManager iterating over
a all iframes of a window when queried for its capture state.
It is fine however, since GeckoViewMedia already iterates over all windows in
MediaManagerService.activeMediaCaptureWindows, which includes all subframes that
are actively captured.
This patch removes IterateWindowListeners altogether, and the last callsite is
simplified.
Differential Revision: https://phabricator.services.mozilla.com/D93079