Now hal uses AR_STATE for screen orientation, so we should move it from
WinUtils.cpp to WinUtils.h for newer Windows 11 SDK.
Also, newer Windows SDK has to set WINVER to WIN8 to use auto rotation API.
Differential Revision: https://phabricator.services.mozilla.com/D163099
Since Windows tablet mode has a orientation lock API, this patch
implements orientation lock backend for Windows tablet mode.
`GetAutoRotationState` API recognizes whether orientation API is supported on
the device. So this fix uses this API to check orientation API capability.
Differential Revision: https://phabricator.services.mozilla.com/D162451
This fixes the snap layouts feature on Windows 11.
Instead of using a content attribute (which is somewhat expensive to
look up) use the default appearance and do this where we deal with other
appearance hacks (before building themed backgrounds).
Consolidate this inside a DealWithWindowsAppearanceHacks function along
with the glass stuff.
Differential Revision: https://phabricator.services.mozilla.com/D162757
This fixes bug 1799460 for good. You can test this on Win10 with
browser.display.windows.non_native_menus=0 or HCM, but same applies to
Win7/8.
The front-end sets their own sizes anyways, and when the windows sizes
are less than the ones the front-end sets, we see that bug.
This is rather annoying because, even though it's fixable (we can fix
the intrinsic sizing code in the web to deal with this properly), it's
probably not worth fixing, as no web-exposed widget has a min-widget
size other than scrollbars and internal form control parts.
Removing this code altogether just works, since as I said before the
front-end sizes the menu parts anyways, so enforcing a given size in C++
is not necessary.
Differential Revision: https://phabricator.services.mozilla.com/D162709
We used to provide links to the bug numbers but this was broken
somewhere along the way. Now it is provided the failure IDs from which
it can attempt to extract a bug number, as well as always display any
failure ID and message whenever possible.
Differential Revision: https://phabricator.services.mozilla.com/D162734
- Remove nsDragService::CreateURIList() and replace it by nsDragService::SourceDataGetUriList().
It reads all items from nsITransferable and put them to uri list.
If data drop is performed to another application which doesn't have access to internal data storages (mailbox:// for instance),
request download and save referenced items to /tmp directory.
- Implement SourceDataAppendURLItem() which read one item from nsITransferable and append it to uri list.
Download and store internal files in /tmp directory.
- Make CreateTempFile() to block native events processing. nsIOutputStream/nsIInputStream read and write operations run
event loop and can abort D&D operation before we write all data to /tmp. Use nsAppShell to block native event processing
during read/write to prevent it.
Differential Revision: https://phabricator.services.mozilla.com/D162473
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
And initialized it only in ctors so that in the next change we can use it to
tell whether this pan event may trigger swipe or not without calling
SwipeTracker::CanTriggerSwipe every time.
There's an unintuitive change in a GTest sending a horizontal pan-start event.
With this changeset, all incomming pan-start events on desktop platforms
basically set mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection
to true even if the event is generated in GTests. So the pan start event runs
into the short circuit path for swipe-to-navigation. This is a good thing because
it means the GTest replicates what our browser does properly.
Differential Revision: https://phabricator.services.mozilla.com/D160435
There's a bug (bug 1800022) that wheel event listeners in the browser process
badly interact with overscroll even so we'd avoid the bug here.
Differential Revision: https://phabricator.services.mozilla.com/D161752
Otherwise prefs set in the previous test case will persist. In fact
some of test cases were lacking "browser.swipe.navigation-icon-move-distance".
Differential Revision: https://phabricator.services.mozilla.com/D161751
One thing to note is that if the user shrinks this number we won't reclaim any memory - this is because I wanted to avoid doing any more work than necessary when we're logging messages. Let me know if you think this is a problem!
Differential Revision: https://phabricator.services.mozilla.com/D161156
At :handyman's suggestion, just removing the messages when we get a WM_DESTROY message works great and is way less complicated than the previous version of this :-)
Differential Revision: https://phabricator.services.mozilla.com/D161155
This is the list of messages that handyman and rkraesig suggested.
Since we're recording WM_GETMINMAXINFO, we now have better logging for that message.
Differential Revision: https://phabricator.services.mozilla.com/D161150
This is helpful for the normal event log, and also necessary since we want to group the messages up by window in the about page.
Differential Revision: https://phabricator.services.mozilla.com/D161149
The change disables ZeroCopyNV12Texture for checking if the video overlay works without ZeroCopyNV12Texture with non-intel GPU.
For now, on release, ZeroCopyNV12Texture is not enabled with non-intel GPUs. It blocks to enable video overlay with non-intel GPUs. Then it seems better to enable video overlay with non-intel GPUs on release without ZeroCopyNV12Texture if possible.
Differential Revision: https://phabricator.services.mozilla.com/D160744
One thing to note is that if the user shrinks this number we won't reclaim any memory - this is because I wanted to avoid doing any more work than necessary when we're logging messages. Let me know if you think this is a problem!
Differential Revision: https://phabricator.services.mozilla.com/D161156
At :handyman's suggestion, just removing the messages when we get a WM_DESTROY message works great and is way less complicated than the previous version of this :-)
Differential Revision: https://phabricator.services.mozilla.com/D161155
This is the list of messages that handyman and rkraesig suggested.
Since we're recording WM_GETMINMAXINFO, we now have better logging for that message.
Differential Revision: https://phabricator.services.mozilla.com/D161150
This is helpful for the normal event log, and also necessary since we want to group the messages up by window in the about page.
Differential Revision: https://phabricator.services.mozilla.com/D161149
So that APZ can wait to handle the event to do overscrolling until the browser
responds that the event wasn't used for gestures.
Differential Revision: https://phabricator.services.mozilla.com/D160438
And rename mRequiresContentResponseIfCannotScrollHorizontallyInStartDirection to
mMayTriggerSwipe.
So basically once after the flag is set, we should use it.
Differential Revision: https://phabricator.services.mozilla.com/D160436
Cristian Tuns
Barret Rennie
Stanca Serban
Makoto Kato
stransky
Edgar Chen
Emilio Cobos Álvarez
Andrew Osmond
Hiroyuki Ikezoe
Greg Stoll
sotaro
Butkovits Atila
Tom Schuster