We decided to keep it when initially making scrollbars non-native, but I think
it's time for it to go, since it's pretty much untested.
Nobody has complained about the non-native scrollbars in chrome documents, and
the GTK scrollbar implementation is not suitable for content because it doesn't
support scrollbar-width among other things.
Differential Revision: https://phabricator.services.mozilla.com/D135670
Since bug 1747116 landed, if the compositor is reinitialized whilst
the Android Surface is invalid, we avoid crashing when querying the
window size and instead keep the compositor in a paused state.
However, in this case we will believe the widget size is 0x0 until the
compositor is eventually resumed. If webrender receives a display list
during this time, it will set an empty view rect. This means when the
compositor is subsequently resumed webrender believes it has nothing
to render, and we get stuck in a state where nothing is ever rendered
to the screen.
This patch initializes the AndroidCompositorWidget with an initial
size, which avoids the problem.
Differential Revision: https://phabricator.services.mozilla.com/D135711
We have this situation right now where all the themes are inheriting from
nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at
it.
In the future I'd like to simplify the inheritance chain to remove
nsNativeTheme altogether (so that all nsITheme implementations use
mozilla::widget::Theme).
That's not hard to do mechanically, but rather than dumping all of
nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully
remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on
and use something nicer. Eventually the inheritance chain will be something
like:
* nsITheme : public nsISupports
* Theme : public nsITheme, public nsITimerCallback, public nsINamed
* ThemeCocoa : public Theme
* nsNativeThemeCocoa : public ThemeCocoa
* nsNativeThemeWin : public Theme
* nsNativeThemeGtk : public Theme
Differential Revision: https://phabricator.services.mozilla.com/D135668
This allows MSIX-installed Firefox to be launched through Win+r and Powershell (and probably other places). This feels deceptively simple - but it appears to work.
Differential Revision: https://phabricator.services.mozilla.com/D135638
nsPresContest::RegisterManagedPostRefreshObserver still lets us add a managed post refresh observer until the mPresShell pointer on the prescontent is nulled out. That means that between the call to CancelManagedPostRefreshObservers and mPresContext->DetachPresShell() (which nulls out the mPresShell pointer on the prescontext) in PresShell::Destroy we can add a managed post refresh observer that will never get removed. Notably, destroying the frame tree happens between these two calls.
So move the CancelManagedPostRefreshObservers call to happen right after we null out the mPresShell pointer on the prescontext.
In bug 1737503 I want to add a managed post refresh observer when we destroy a subdocument frame (it's only interested in the recreate frames case not the destruction case, but not an easy way to tell them apart afaik), so it triggers this bug. The patch and test I have for that bug exercise this scenario.
Differential Revision: https://phabricator.services.mozilla.com/D135340
This patch adds a checkbox at the end of each event listeners in the EventTooltip,
which allow the user to disable/re-enable a given event listener.
This is done by managing a Map of nsIEventListenerInfo object in the NodeActor,
which we populate from `getEventListenerInfo`. Each `nsIEventListenerInfo` is
assigned a generated id, which can then be used to call the new NodeActor
methods, `(enable|disable)EventListener`.
We don't support disabling jquery/React event listeners at the moment, so we
display the checkbox for them as well, but disabled.
Differential Revision: https://phabricator.services.mozilla.com/D135133
`PrintUsageThenExit(code)` was supposed to exit when `code` was not zero, but:
- The name didn't reflect that, so it was confusing that `PrintUsageThenExit(0)` would *not* exit.
- The implementation in the Base Profiler exited anyway! This caused issues with some legacy code that still used the now-removed "threads" feature.
This patch renames the function to just `PrintUsage()` and never exits, leaving the caller to invoke `exit(code)` as needed -- with the added benefit that it's possible to exit with a zero code, useful in cases where an exit is not actually an error.
Differential Revision: https://phabricator.services.mozilla.com/D135666
This patch includes:
- a new xpcshell-serviceworker.ini manifest, all tests included in this manifest will also run in the
"background service worker mode", initially including all `alarms` API xpcshell tests
- some small changes to test_ext_alarms.js to temporarily skip test case that can't yet pass
while running in "background service worker mode" (until fixed in separate followups)
- some small tweaks to head_service_worker.js to avoid failure due to an existing ExtensionCommon
const bindings being redefined while running a test for the xpcshell-remote.ini manifest
Differential Revision: https://phabricator.services.mozilla.com/D135125
Provide a way to use service workers as the background script in existing tests, possibly by only
requiring minimal changes to the existing test cases.
This patch includes:
- changes needed to detect when a test extension is being created for a test running in
the "background service worker mode" and automatically turn the background script into
a background service worker (instead of a background page) when not explicitly listed
in the test extension manifest
- a new mochitest-serviceworker.ini manifest where new or existing test files meant to be run on a
background service worker can be added to run them automatically in the "background service worker mode"
- a new test_verify_sw_mode.html smoke test that make sure the mochitest-serviceworker.ini manifest
is running in the expected mode.
- a new `sw-webextension` tag, which can be used locally to run a test file only in the
"background service worker mode"
- changes to test_ext_test.html to make it able to run in both background pages and background workers
- small tweaks to `test` API (both the WebIDL binding and the current bindings injected from privileged
js code, to better match each other behavior)
Differential Revision: https://phabricator.services.mozilla.com/D122536
This is a pretty unique special-case; in general, Indic-script VIRAMA characters
cluster with the preceding base, but in Bengali (Bangla) script, VIRAMA combines
with a *following* YA to create the ya-phala form, which as a whole then needs to
stay associated with the preceding letter.
This works for us if the font ligates the entire letter + ya-phala cluster, but
if ya-phala remains a separate glyph then we could introduce unwanted spacing.
Checking for this case in SetupClusterBoundaries enables us to ensure that the
entire letter + ya-phala cluster stays together, regardless of the specifics of
the font implementation.
Differential Revision: https://phabricator.services.mozilla.com/D135347
