Otherwise we hit the weird HTML-specific lowercasing of attributes,
which make these attributes "screenx" and "screeny", which means we fail
to restore the persisted position.
We should consider adding screen-x/screen-y and migrate screenX/Y to
that probably...
Differential Revision: https://phabricator.services.mozilla.com/D162391
[Int]CoordTyped no longer inherits Units because otherwise
instances of [Int]IntPointTyped may get one Base subobject because
it inherits Units, and others because of BasePoint's Coord members,
which end up increasing the [Int]CoordTyped's objects size (since
according to the ISO C++ standard, different Base subobject are
required to have different addresses).
Differential Revision: https://phabricator.services.mozilla.com/D160713
Much like everything else. This is important because the front-end uses
sizemode for styling.
The comment I'm removing doesn't really make much sense, since sizemode
and size are persisted separately (using different dirty flags) so it's
not like we're saving duplicate work or something.
The delay this fixes existed already on Linux since ~forever at least,
haven't tested macOS.
Depends on D159578
Differential Revision: https://phabricator.services.mozilla.com/D159579
Much like everything else. This is important because the front-end uses
sizemode for styling.
The comment I'm removing doesn't really make much sense, since sizemode
and size are persisted separately (using different dirty flags) so it's
not like we're saving duplicate work or something.
The delay this fixes existed already on Linux since ~forever at least,
haven't tested macOS.
Depends on D159578
Differential Revision: https://phabricator.services.mozilla.com/D159579
This fixes issues like the one that got me backed out, where we have a
dirty size request, and we want to synchronously persist sizemode.
With this patch, we'd persist sizemode sync, but size would still be
updated async, preserving the previous size behavior.
Differential Revision: https://phabricator.services.mozilla.com/D159644
Much like everything else. This is important because the front-end uses
sizemode for styling.
The comment I'm removing doesn't really make much sense, since sizemode
and size are persisted separately (using different dirty flags) so it's
not like we're saving duplicate work or something.
The delay this fixes existed already on Linux since ~forever at least,
haven't tested macOS.
Depends on D159578
Differential Revision: https://phabricator.services.mozilla.com/D159579
This patch doesn't change behavior by itself, but it makes the
persistent attribute code a bit clearer by making it use typed enums
rather than raw integers for flags. Also centralizes the update.
Depends on D159577
Differential Revision: https://phabricator.services.mozilla.com/D159578
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
This is the listener for a size mode change, shouldn't need to set the
size mode again. While at it, match coding style better.
This doesn't change behavior now, but with the next patch it would.
Differential Revision: https://phabricator.services.mozilla.com/D157597
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Otherwise, it changes the move-to-rect inputs, which can change the
output as well, making us move the anchor all the way to the right.
You could, I guess, consider this a mutter bug of sorts, because it
feels weird that you pass it an anchor that has been a `move-to-rect`
output and you get another rect as an output.
But also, it's kinda silly that we're doing that to begin with, so avoid
it by telling the popup frame whether it's been positioned / moved by
move-to-rect (and keeping the anchor in that case).
The reason this works on my setup without "Large text" is just dumb luck
(the front-end computes a max-height for the panel that is small enough
to fit on the screen).
Differential Revision: https://phabricator.services.mozilla.com/D155406
Previously we would pull this information frequently from the subject
principal, which is unreliable. With this new approach, we more explicitly pass
the principals around as-needed into where they're going to be used.
Some assertions about the subject principal were introduced to ensure that
assumptions made about chrome windows and the system principal are not
incorrect.
Differential Revision: https://phabricator.services.mozilla.com/D154563
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
This simplifies a bit the tabbrowser/tab switcher code, and makes it
work in all windows.
The WPT failures are due to bug 1780212.
Differential Revision: https://phabricator.services.mozilla.com/D151822
So, the problem was just that in LoadNativeMenus, we do our cleanup of the
sLoadNativeMenusListeners list. However, we were also early exiting from that
function if we're in headless mode. We have no good reason to be in that
function to begin with if we're in headless mode though, so I just hoisted
the check out to an earlier point.
Differential Revision: https://phabricator.services.mozilla.com/D151929
This does fix the Pre-XUL skeleton UI scaling for me, but the others are
harmless and I can't repro the bug as described.
I _guess_ this can happen if you have window borders on Windows, since we were
mishandling those? But I don't know how to get those on Win10+.
The other scalings are symmetrical so they ended up working out in the end. In
any case this is the right thing to do and I'm ~sure it will fix the bug in the
reporter's configuration.
Differential Revision: https://phabricator.services.mozilla.com/D149449
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
In bug 1773342 I made OS text scale factor behave like a full zoom
factor which applies to all pages (including the browser chrome). That's
generally straight forward but it makes some callsites that use unzoomed
CSS coordinates misbehave (or behave correctly accidentally actually in
some other cases).
The main fix here is making
nsIBaseWindow::UnscaledDevicePixelsPerCSSPixel() and
nsIScreen::GetDefaultCSSScaleFactor() account for OS zoom as necessary.
However, I also went through the relevant code and cleaned it up to use
typed units and operations when possible.
The setup means:
* nsIWidget::GetDefaultScale() doesn't account for OS full zoom.
* nsIBaseWindow and nsIScreen does.
These are the places where this should matter and stuff can get
confused, but this works surprisingly well for all callers (except one
nsDeviceContext one which we use only for PuppetWidget and we can
remove by falling back to 1.0 like all other widgets until the update
comes).
Differential Revision: https://phabricator.services.mozilla.com/D149033
The biggest set of APIs from ns[T]StringObsolete which are still heavily used
are the string searching APIs. It appears the intention was for these to be
replaced by the `FindInReadable` APIs, however that doesn't appear to have
happened.
In addition, the APIs have some quirks around their handling of mixed character
widths. These APIs generally supported both narrow strings and the native
string type, probably because char16_t string literals weren't available until
c++11. Finally they also used easy-to-confuse unlabeled boolean and integer
optional arguments to control behaviour.
These patches do the following major changes to the searching APIs:
1. The ASCII case-insensitive search method was split out as
LowerCaseFindASCII, rather than using a boolean. This should be less
error-prone and more explicit, and allows the method to continue to use
narrow string literals for all string types (as only ASCII is supported).
2. The other [R]Find methods were restricted to only support arguments with
matching character types. I considered adding a FindASCII method which would
use narrow string literals for both wide and narrow strings but it would've
been the same amount of work as changing all of the literals to unicode
literals.
This ends up being the bulk of the changes in the patch.
3. All find methods were re-implemented using std::basic_string_view's find
algorithm or stl algorithms to reduce code complexity, and avoid the need to
carry around the logic from nsStringObsolete.cpp.
4. The implementations were moved to nsTStringRepr.cpp.
5. An overload of Find was added to try to catch callers which previously
called `Find(..., false)` or `Find(..., true)` to set case-sensitivity, due
to booleans normally implicitly coercing to `index_type`. This should
probably be removed at some point, but may be useful during the transition.
Differential Revision: https://phabricator.services.mozilla.com/D148300
