Make it return a margin from client area to window area, and add an
explicit function to get the size difference.
No behavior change.
Depends on D166428
Differential Revision: https://phabricator.services.mozilla.com/D166431
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
This changes the behavior in a few ways:
- the 'active' notification is now only fired when a new user event has been received by Firefox, rather than by any application on the entire system.
- the 'active' notification will fire immediately when Firefox receives a new event. Before the patch is was fired within 5s of the user returning on some plateforms (eg. Mac) and immediately on some other platforms that already called ResetIdleTimeout (windows, gtk, android). I'm not sure if these existing calls to ResetIdleTimeout are really needed, nor if they add significant overhead.
- when an idle observer has been notified of 'idle', it won't be notified again until Firefox receives events. Before the patch, if the user used other applications while Firefox was in the background, we would keep sending active and idle notifications to our idle observers. This behavior was probably initially intended when the nsUserIdleService was introduced to support the use case of instant messaging clients, but doesn't seem to match the expectations of the existing consumers of the service.
Differential Revision: https://phabricator.services.mozilla.com/D166306
The way the code was set up before this patch ends up causing minimum
scrollbar sizes to be 0x0 for thin (non-overlay) scrollbars.
This is rather problematic, since it means that we would always try to
place the scrollbar even if it doesn't fit (think of an element with
height: 0).
This causes a lot of extra reflow, which with very complex layouts is
even worse, because the extra scrollframe reflows cause us to miss the
flex caches, causing O(n^2) performance.
Add assertions to make sure we never end up with a zero minimum
scrollbar size, and change the size computation to match for both
thin and thick scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D166756
The way the code was set up before this patch ends up causing minimum
scrollbar sizes to be 0x0 for thin (non-overlay) scrollbars.
This is rather problematic, since it means that we would always try to
place the scrollbar even if it doesn't fit (think of an element with
height: 0).
This causes a lot of extra reflow, which with very complex layouts is
even worse, because the extra scrollframe reflows cause us to miss the
flex caches, causing O(n^2) performance.
Add assertions to make sure we never end up with a zero minimum
scrollbar size, and change the size computation to match for both
thin and thick scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D166756
I wrote this while debugging / fixing bug 1806438, and this is kind of
related and needed to fix that bug in one of my machines.
This ensures that all size mode changes go through a central place.
In order to do that, we need to pass whether we need to ShowWindow()
since doing it redundantly in some cases like windows-triggered sizemode
changes would break stuff.
Differential Revision: https://phabricator.services.mozilla.com/D166254
Otherwise we might restore nonsensical bounds because Windows moves
minimized windows to crazy positions like -32000, -32000.
Differential Revision: https://phabricator.services.mozilla.com/D165913
Properly test for and handle errors in target-surface creation and
mapping.
(Additionally, perform some drive-by cleanup/modernization.)
Differential Revision: https://phabricator.services.mozilla.com/D166126
- Implement DataPromiseHandler class to hold clipboard data promise and related data during async gtk_clipboard_request_text/gtk_clipboard_request_contents call.
- Implement AsyncGetTextImpl() helper to get text from clipboard.
- Implement AsyncGetDataImpl() helper to get general data from clipboard.
- Implement nsClipboard::AsyncGetData() handler.
Differential Revision: https://phabricator.services.mozilla.com/D163925
When a notification's originating tab is closed, it remains in the action center and launches to the originating domain when clicked. When the notification is from a private browsing session, the originating domain leaks to a non-private context when a private browsing session is still active. This fixes the leak by closing the notification with it's originating tab.
Differential Revision: https://phabricator.services.mozilla.com/D164296
This adds context to `CloseAlert()` such that explicitly closing the notification e.g. `notification.close()` can be differentiated from a tab or window implicitly closing the notification. This is necessary as we want notifications to persist after a tab or window is closed for Windows.
This change in behavior is necessary to match user expectations. Users expect notifications to persist in the system tray and do not expect notifications to be lost due to a tab being closed. The content of the message is more important than the interaction in that lens. This change is also necessary for parity with Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D161024
Notifications are now routed through a notification DLL server, which receives permission to set the foreground window when invoked. When the server launches Firefox, the command line is redirected to the currently running application. An instance of Firefox running as a remote client doesn't meet Window's criteria for receiving the set foreground permission, breaking the chain of set foreground window permissions.
This change fixes the chain by piping the PID of the notification handling process such that the DLL server can grant it foreground permission directly.
Differential Revision: https://phabricator.services.mozilla.com/D160457
We need to ensure we're not in a `WndProc` callback context when interacting with native notification COM objects, which is currently a problem when called from the command line handler (see Bug 1805802). We achieve this by moving COM work onto a background task which defers processing until after `WndProc` returns.
Now that retrieving the fallback URL occurs on a background task waiting for it before returning would block the main thread. Making `handleWindowsTag` async introduced race conditions with commandline handling, requiring a `enterLastWindowClosingSurvivalArea`/`exitLastWindowClosingSurvivalArea` to prevent misbehavior in case early blank window is pref'd off. In order to simplify exit cleanup, the API was updated to return a `Promise`.
Differential Revision: https://phabricator.services.mozilla.com/D160458
Emilio Cobos Álvarez
Cosmin Sabou
stransky
Florian Quèze
Edgar Chen
Neil Deakin
Otto Länd
serge-sans-paille
Cristian Tuns
Noemi Erli
Ray Kraesig
David Shin
Tyler Paplham
Matthew Noorenberghe
Sandor Molnar
Nicholas Rishel