This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This simplifies LexicalEnvironmentObject::thisValue so it's easier to inline in JIT code.
Differential Revision: https://phabricator.services.mozilla.com/D16586
--HG--
extra : moz-landing-system : lando
Our accSelection implementation always returns an IUnknown which clients QI to IEnumVARIANT.
Marshaling as IUnknown works fine in this case, but it's more efficient and correct to marshal the correct interface.
Also, without this, we'd hit an assertion.
Depends on D16662
Differential Revision: https://phabricator.services.mozilla.com/D16663
--HG--
extra : moz-landing-system : lando
We only use the handler for specific interfaces such as IAccessible* and IAccessibleHyperlink.
For interfaces which don't use the handler, we currently write an empty payload, but this still adds bytes to the stream.
This seems to break marshaling such an interface in a VT_UNKNOWN in a VARIANT.
To fix this, just don't write any payload at all when we aren't using the handler for the target interface.
Differential Revision: https://phabricator.services.mozilla.com/D16662
--HG--
extra : moz-landing-system : lando
Under WOW64, the SysWOW64 directory is the effective system directory. A flag
has been added (ModuleTrustFlags::SysWOW64Directory) representing this
directory, and we now grant this the same trustworthiness as
ModuleTrustFlags::SystemDirectory.
Depends on D16013
Differential Revision: https://phabricator.services.mozilla.com/D16160
--HG--
extra : moz-landing-system : lando
This patch:
- Adds two new fields to the untrusted modules ping
- Updates documentation for the untrusted modules ping:
- Documents these 2 new fields
- Documents the new XUL ModuleTrustFlags bitfield value
- Adds a "version history" section
- Corrects documentation for ModuleTrustFlags (JIT, keyboard layouts)
Differential Revision: https://phabricator.services.mozilla.com/D16013
--HG--
extra : moz-landing-system : lando
In order to help unify DLL timings across machines with different performance
characteristics, this change collects the load duration of xul.dll.
Because xul.dll is always loaded, it can serve as a control value for DLL load
times.
Differential Revision: https://phabricator.services.mozilla.com/D16012
--HG--
extra : moz-landing-system : lando
This patch measures the duration of module loads and passes it up to
UntrustedModulesManager where, in later patches, it will be consumed by
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D16011
--HG--
extra : moz-landing-system : lando
This does two things:
* Ensures that the T gets dropped when the item is removal, which is
important for the TextRunKey case where it holds heap memory.
* Eliminates the epoch handling while still ensuring that we panic on
stale lookups.
We also remove the Item usage for local_data, but don't bother with the
Option in that case.
Differential Revision: https://phabricator.services.mozilla.com/D16629
WindowsDllBlocklist installs a callback function that fires whenever a DLL
is loaded. The installer function shares an SRWLock with the callback
function.
SRWLock is not re-entrant, so if the installer function accidently causes a
DLL load before releasing the lock, the callback function will deadlock.
This occured trying to solve Bug 1402282, where the installer function used
"new" to allocate memory, which called the Win32 "RtlGenRandom()" function,
which loaded bcrypt.dll, which caused the callback to fire off, which tried
to lock the mutex that was already locked by the installer function.
Hopefully this will save another developer lots of debug time in the future by
turning a difficult-to-debug deadlock into a nice, loud assertion.
Differential Revision: https://phabricator.services.mozilla.com/D15840
--HG--
extra : moz-landing-system : lando
The scroll anchoring bounding rect of a node can be influenced by absolutely
positioned descendants with very negative offsets. This can cause undesired
scroll adjustments, and has been seen on the web in Gmail. The spec needs to
be amended to say what to do here. Chrome currently will clamp the vertical
offset. This commit implements a stop-gap to clamp the negative portions to
fix this issue, while we do more research and spec-work.
Differential Revision: https://phabricator.services.mozilla.com/D16625
--HG--
extra : rebase_source : 882ac29fca602ae398ffa74bf5747a8eeb4e9329
extra : amend_source : b6537c3626c5bae60285a4e55399b69ad52206b4
extra : source : ecc18f11431e2da2676962c82962932b4465fb38
We need a test-only IPC message to socket process to trigger the Telemetry::Scalar set since no js engine in the socket process.
And hook the IPC call to AddPendingEvent |CallOrWaitSocketProcess| introduced by bug 1496257.
Differential Revision: https://phabricator.services.mozilla.com/D14822
--HG--
extra : moz-landing-system : lando
For some reason that I could not figure out, usage of any https host in these getUserMedia mochitests
on Android causes a network proxy error and will, in this particular case, lead to the iframe not
loading the test page. This causes our test to timeout.
I don't think testing https here is particularly important, and so I'd rather save some
effort for myself and just remove it.
Differential Revision: https://phabricator.services.mozilla.com/D16538
--HG--
extra : moz-landing-system : lando
Currently there are two conditions where CONTENT_FRAME_TIME_REASON can
be NoVsync. Since, were getting an appreciable amount of these with
WebRender it makes sense to split out the telemetry so that we can
confirm which scenario we're hitting.
Differential Revision: https://phabricator.services.mozilla.com/D16611
--HG--
extra : moz-landing-system : lando
These tests make sure that passing alwaysOnTop as a window feature
results in a window with WS_EX_TOPMOST, and also ensures that web
content cannot request alwaysOnTop windows.
Differential Revision: https://phabricator.services.mozilla.com/D16570
--HG--
extra : moz-landing-system : lando
Cloud Storage initialize provider test to help fix intermittent test failures
Differential Revision: https://phabricator.services.mozilla.com/D15998
--HG--
extra : moz-landing-system : lando
