The ProfilingStack object inside ThreadRegistrationData is guaranteed to live while the thread is registered (and alive), and all accesses are guaranteed to be done either:
- On-thread, so during that time ThreadRegistrationData and its ProfilingStack cannot be destroyed.
- From another thread, but with the Profiler lock and/or per-thread lock, which also guarantees that ThreadRegistrationData and its ProfilingStack cannot be destroyed.
RacyRegisteredThread brought some doubts about end-of-thread accesses, that why there's was an intermediate ref-counted ProfilingStackOwner to keep ProfilingStack alive where needed. Now we can remove it.
Also the separate TLS (Thread Local Storage) for ProfilingStackOwner can be removed, since we can reach the ProfilingStack through the ThreadRegistration TLS for the same cost.
Differential Revision: https://phabricator.services.mozilla.com/D121846
This works, but there's an issue dealing with dynamic changes. I'm
almost sure that's a GTK issue, will try to file and repro.
Differential Revision: https://phabricator.services.mozilla.com/D122584
Perform additional encoding of URLs before converting to an NSURL as required per the `NSURL URLWithString:` method documentation.
Differential Revision: https://phabricator.services.mozilla.com/D122653
The ProfilingStack object inside ThreadRegistrationData is guaranteed to live while the thread is registered (and alive), and all accesses are guaranteed to be done either:
- On-thread, so during that time ThreadRegistrationData and its ProfilingStack cannot be destroyed.
- From another thread, but with the Profiler lock and/or per-thread lock, which also guarantees that ThreadRegistrationData and its ProfilingStack cannot be destroyed.
RacyRegisteredThread brought some doubts about end-of-thread accesses, that why there's was an intermediate ref-counted ProfilingStackOwner to keep ProfilingStack alive where needed. Now we can remove it.
Also the separate TLS (Thread Local Storage) for ProfilingStackOwner can be removed, since we can reach the ProfilingStack through the ThreadRegistration TLS for the same cost.
Differential Revision: https://phabricator.services.mozilla.com/D121846
This is simpler and more correct, the previous code could get sHCursor and
sCurrentCursor out of sync, which caused this issue.
Differential Revision: https://phabricator.services.mozilla.com/D122966
When re-focusing input type that has the prompt such as `<input type=week>`,
we show software keyboard unfortunately. We shouldn't show it.
Differential Revision: https://phabricator.services.mozilla.com/D122198
AFAICT, all roads lead though [`nsAppStartup::Quit`](https://searchfox.org/mozilla-central/rev/0fec57c05d3996cc00c55a66f20dd5793a9bfb5d/toolkit/components/startup/nsAppStartup.cpp#448),
which is responsible for firing the `"quit-application"` observer notification
and then posting the `nsAppExitEvent` that causes the `nsAppShell` to break out
of its event loop and proceed with shutdown.
If we trigger a native crash in the observer, we should be able to capture a
symbolicated stack of whatever called `Quit`. We might as well force-crash
anyway, since AC is going to throw an exception regardless...
Before we crash, we annotate the current `GeckoThread` state to enable us to
find out whether we were fully initialized at the time of the shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D122256
This makes Firefox respect the following Windows registry key:
Computer\HKEY_CURRENT_USER\Control Panel\Desktop\CaretTimeout
Which makes the caret stop blinking after a given timeout, and thus stop
wasting CPU.
Differential Revision: https://phabricator.services.mozilla.com/D122501
MOZ_WEBRENDER=0 now does nothing -- you will either get HW-WR or SW-WR
depending on the platform configuration. The pref
gfx.webrender.force-legacy-layers is removed. This leaves no
configuration option to disable WebRender.
MOZ_WEBRENDER=1 will continue to force WR on, which will ensure in CI we
get HW-WR unless gfx.webrender.software is true.
Differential Revision: https://phabricator.services.mozilla.com/D122474
AFAICT, all roads lead though [`nsAppStartup::Quit`](https://searchfox.org/mozilla-central/rev/0fec57c05d3996cc00c55a66f20dd5793a9bfb5d/toolkit/components/startup/nsAppStartup.cpp#448),
which is responsible for firing the `"quit-application"` observer notification
and then posting the `nsAppExitEvent` that causes the `nsAppShell` to break out
of its event loop and proceed with shutdown.
If we trigger a native crash in the observer, we should be able to capture a
symbolicated stack of whatever called `Quit`. We might as well force-crash
anyway, since AC is going to throw an exception regardless...
Before we crash, we annotate the current `GeckoThread` state to enable us to
find out whether we were fully initialized at the time of the shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D122256
This workaround was removed in D121650. Unfortunately we need it
a bit longer until the Mutter fix reaches users, as triggering it
crashes the whole desktop.
Differential Revision: https://phabricator.services.mozilla.com/D122460
Jeff Muizelaar
Paul Adenot
stransky
Gerald Squelart
Matt Woodrow
Harry Twyford
Emilio Cobos Álvarez
Kagami Sascha Rosylight
Andi-Bogdan Postelnicu
Iulian Moraru
Butkovits Atila
Haik Aftandilian
Stephen A Pohl
Cosmin Sabou
David Parks
Edgar Chen
Alexandru Michis
Brindusan Cristian
Karl Tomlinson
Makoto Kato
Eitan Isaacson
Marian-Vasile Laza
Aaron Klotz
hmh
Andrew Osmond
Dorel Luca
Robert Mader