This code is used to determine the sizes of the top-level windows. However the
code doesn't cause quite desirable behavior (see the bug, and comment 15).
This patch does two things:
* Unifies the html / xul code-paths. This shouldn't change behavior (because
GetXULMinSize returns the fixed min-* property if present anyways), but
makes the patch a bit simpler.
* Makes the min-width of the XUL window be the pref size instead of the
min-size (for the cases where you have no explicit min-width). This looks a
bit counter intuitive, but it's the only way to guarantee that the content
will be shown. This matches the sizing algorithm that dialogs use by default
(via calling window.sizeToContent()), while allowing to undersize the window
via a fixed min-width property.
This in turn makes sizeToContent() work "by default" on XUL windows, avoiding
having to make JS listen to everything that possibly could change the layout of
the document (like resolution changes).
Differential Revision: https://phabricator.services.mozilla.com/D70209
If we get a sub-pixel content size, rounding down may actually cause the content
to wrap, which is not desirable and would cause the content to be truncated.
Differential Revision: https://phabricator.services.mozilla.com/D69744
This fixes the case where you have a focused input (or selection for <input
disabled>) in an <iframe> and move the focus outside of the iframe.
Differential Revision: https://phabricator.services.mozilla.com/D67596
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
This rejiggers a bit the way selection focus is handled so that focusing a
disabled form control with the mouse handles selection properly, and hides the
document selection and so on.
This matches the behavior of other browsers as far as I can tell.
Given now readonly and disabled editors behave the same, we can simplify a bit
the surrounding editor code.
Differential Revision: https://phabricator.services.mozilla.com/D66464
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
Since safe area insets uses on content, we need send it from chrome process to
content process.
SafeAreaInsetsChanged will be called per window position/size change (Next
patch is Android implementation for it), we have to calculate safe area insets
on widget/window per change.
Current implementation is that this value is top level document only like Blink
since https://github.com/w3c/csswg-drafts/issues/4670 isn't resolved yet.
Differential Revision: https://phabricator.services.mozilla.com/D55084
It's a better name, and will avoid confusion when I add other stylesheet caches
outside of the CSS loader.
Depends on D54556
Differential Revision: https://phabricator.services.mozilla.com/D54557
This patch adds a menu item in "Toggle" -> "Paged Mode". If the item is
toggled, after finishing loading the document, the document will be
forced into paged mode.
The print settings in `nsLayoutDebuggingTools::SetPagedMode()` are
similar to `setupPrintMode()` in reftest-content.js.
Remove the hack in nsDocumentViewer::InitInternal() because we don't
want to set a new document when mIsPageMode = false.
Differential Revision: https://phabricator.services.mozilla.com/D49993
The PreFullZoomChange event gives listeners an opportunity to capture
state before the viewport full zoom changes. Responsive Design Mode uses
this to save and later restore the resolution of the RDM pane.
Differential Revision: https://phabricator.services.mozilla.com/D48621
The PreFullZoomChange event gives listeners an opportunity to capture
state before the viewport full zoom changes. Responsive Design Mode uses
this to save and later restore the resolution of the RDM pane.
Differential Revision: https://phabricator.services.mozilla.com/D48621
The PreFullZoomChange event gives listeners an opportunity to capture
state before the viewport full zoom changes. Responsive Design Mode uses
this to save and later restore the resolution of the RDM pane.
Differential Revision: https://phabricator.services.mozilla.com/D48621
In particular, not let ResizeReflow take the old and new size. Most of the
callers pass dummy values anyway.
Instead, use the old size of the layout viewport. This ensures we fire resize
events only if the layout viewport actually changes.
This is important because the first resize of the mobile viewport manager
after a navigation has an "old size" of 0x0, even though the layout viewport
is initialized on presshell initialization to the right size.
Thus, we fire resize events unnecessarily in that case, which is the root cause
for bug 1528052.
To do this, we need to shuffle a bit of code in nsDocumentViewer that deals with
delayed resizes, to set the visible area _and_ invalidate layout, rather than
setting the visible area and _then_ relying on doing a resize reflow.
Further cleanup is possible, though not required for my android resizing fix, so
will do separately.
Differential Revision: https://phabricator.services.mozilla.com/D46944
Converted the following to StaticPrefs so that we can easily test variations:
NS_GC_DELAY
NS_SHRINK_GC_BUFFERS_DELAY
NS_FIRST_GC_DELAY
NS_FULL_GC_DELAY
NS_INTERSLICE_GC_DELAY
NS_USER_INTERACTION_INTERVAL
Differential Revision: https://phabricator.services.mozilla.com/D43112
The fixed still worked because we get another SetBounds call right after with the same bounds. But it does mean we are doing some useless invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D42059
All .xul files have been loading as HTMLDocuments for a few weeks now, so
it should be safe to remove the XULDocument implementation.
Differential Revision: https://phabricator.services.mozilla.com/D41238
Not happy with all these void pointer stuff, but I think this is slightly nicer
to read.
Also not happy with what clang-format has done to my code ;)
I've removed the comment about zoom because it's not clear to me it is still
relevant, but I've preserved the order because, should we have similar stuff
going on, it seems slightly better, and I'm moderately sure the rest of the
callers don't really care.
I think closures coerced to function pointers are nicer (I considered putting
this on a template or using std::function, maybe, this was less code specially
given some callers of EnumerateExternalResources may or may not be hot...),
but if you want me to keep stuff out of line, or move the whole thing to
std::function<> or templates let me know.
Differential Revision: https://phabricator.services.mozilla.com/D40249
