The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The constructor of `nsPeekOffsetStruct` and `nsIFrame::GetFrameFromDirection`
take too many `bool` arguments. Therefore, adding new `bool` arguments does
not make sense. Now, we have a useful `mozilla:EnumSet` class to treat them
with an `enum class`. Therefore, let's change `nsPeekOffsetStruct` with it.
Differential Revision: https://phabricator.services.mozilla.com/D172758
The underlying issue here is an invalidation bug with XUL layout. When a
popup opens, we try to lay it out at full size, then post a reflow
callback to constrain it.
There's an intermediate step there where the popup might remain at full
size, and the constraining operates directly on mRect, which isn't quite
sound and doesn't update the scrollport of descendants.
Make nsMenuPopupFrame inherit from nsBlockFrame instead, doing
potentially two layout passes when constrained.
This fixes the issue at hand, and removes XUL layout from menu popups,
so it's a win-win.
To make reasoning about it a bit easier, factor out a bunch of the XUL
positioning code to be const. The mutation of mRect etc which was going
on otherwise was pretty hard to reason about.
Differential Revision: https://phabricator.services.mozilla.com/D170368
For ToResolvedValue implementation purposes we wouldn't need to split
out the vertical / font / line-height arguments and we could just pass
around the ComputedStyle, but the lh unit would need that distinction,
(because computing lh on font properties should use the parent style).
Differential Revision: https://phabricator.services.mozilla.com/D168705
In the description of the mTruncated bit, its purpose is the same as calling
SetInlineLineBreakBeforeAndReset(). We've removed all its usages in previous
patches, so the bit is no longer needed.
Differential Revision: https://phabricator.services.mozilla.com/D151461
The pseudo-class and nsContextMenu context attribute were using reveal,
the pseudo-element and webidl attribute were using "show".
Use reveal consistently and update the accesskey so that there aren't
conflicts with existing commands. Also enable the feature in
browser_contextmenu_input.js so that this change is tested.
Differential Revision: https://phabricator.services.mozilla.com/D136086
Otherwise the origin of the rect might not be correctly converted.
We have a supposed test for something like this:
layout/reftests/forms/input/number/spinner-overflow-vertical.html
But in practice it doesn't work, because I removed the "overflowing
descendants inflate outlines" behavior (bug 1739894), and even with that
pref it doesn't seem to cut it... So repurpose that test to test both.
Differential Revision: https://phabricator.services.mozilla.com/D131175
This frame property's type is small enough to fit directly in the property
table's 64-byte slot; so, this patch makes us store the data directly there
(rather than allocating it externally and storing a pointer in the table).
This patch shouldn't impact behavior at all.
Differential Revision: https://phabricator.services.mozilla.com/D126032
`EventStateManager` gives up to track gesture to start a drag if mouse down
content which is stored in `mGestureDownFrameOwner` gets lost its primary frame.
When user tries to start to drag selected text in `<input>` or `<textarea>`
element, mouse down content is an anonymous node in `TextControlElement`. So,
if a reflow occurs after `mousedown` event, the anonymous `<div>` element
is replaced with new one and `EventStateManager` gives up to track it.
Therefore, this patch makes `EventStateManager` do similar things as
`nsBaseDragService`. When `nsTextControlFrame` notifies of remove/add
the anonymous nodes, `EventStateManager` tries to keep tracking gesture with
a new anonymous node.
Differential Revision: https://phabricator.services.mozilla.com/D119488
When `nsTextControlFrame` is reframed, `TextEditor`, anonymous `<div>`, its
`Text` and the independent `Selection`s are deleted temporarily and recreated
them.
If users are dragging text in `<input>` or `<textarea>`, the drag session's
source node is set to the anonymous text node in the element and the selection
is set to the independent selection. So, if the element is reframed during a
drag, the source node is disconnected from the document and `EndDragSession`
failed to dispatch `eDragEnd` event.
Therefore, this patch makes `nsTextControlFrame` replaces the source node and
selection when it's recreated and only when the drag session's original source
node was in the text control element. For checking which text control had the
anonymous text node, this patch makes `nsTextControlFrame` replaces source
node with the `<input>` or `<textarea>` element when the frame is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D119487
Ideally nsDateTimeControlFrame should / could inherit from
nsTextControlFrame, but this should do for now.
Test also covers the previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D110076
Should be much simpler and doesn't need to deal with the different
stuff. We already have pseudo-classes for this, :autofill and
:placeholder-shown.
I initially wrote this because this is the only limitation that forces
us to have the placeholder text as a direct child of the text control
frame. In the end I kept that as-is, but this simplification is still
worth it.
We remove dom.placeholder.show_on_focus because it doesn't behave
correctly (it doesn't match the :placeholder-shown pseudo-class and it
should). It was introduced in bug 807613 and never turned to false by
default. I suspect nobody will miss this, but if somebody complains
about it we can reintroduce it properly (handling the pref in DOM
instead, changing the right state bits).
Differential Revision: https://phabricator.services.mozilla.com/D108304
This should be a simpler setup. We keep every element being a direct
anon child of the text control, and special case the reflow of the
spinners / clear button, to subtract that size from the other elements.
This fixes the bug by ensuring that the editor and placeholder are sized
and positioned in exactly the same way.
Differential Revision: https://phabricator.services.mozilla.com/D108305
This should be a simpler setup. We keep every element being a direct
anon child of the text control, and special case the reflow of the
spinners / clear button, to subtract that size from the other elements.
This fixes the bug by ensuring that the editor and placeholder are sized
and positioned in exactly the same way.
Differential Revision: https://phabricator.services.mozilla.com/D108305
Emilio Cobos Álvarez