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
This patch calls setSearchMode directly from search(). This sets up a solution for the problem in the bug and also fixes the issue where a call to search() with a restriction token would flicker the token before it was replaced with the search mode indicator. I added new tabmenu and bookmarkmenu entry points to take advantage of this new functionality.
This also fixes the issues with handoff. Besides the problem of search() recording typed for handoff, `handoff` wasn't even registered as a Telemetry probe! That was my mistake. I added a test for handoff telemetry. It was only practical to test it in PBM since it uses a different implementation than about:home that's easier to test. I wrote a lengthy comment above the subtest about why I think this is okay.
Differential Revision: https://phabricator.services.mozilla.com/D91076
Emilio Cobos Álvarez
David Parks
Bogdan Tara
Nika Layzell
Mark Banner
pbz
Tim Huang
Mihai Alexandru Michis
Razvan Maries
Mike Conley
Johann Hofmann
Butkovits Atila
Ricky Stewart
Dorel Luca
Andreas Pehrson
Neil Deakin
Jared Wein
Reid Shinabarker
Steven MacLeod
Narcis Beleuzu
Cameron McCormack
Erica Wright
Noemi Erli
prathiksha
Marco Bonardo
Olli Pettay
Harry Twyford
Csoregi Natalia