The style system uses the changed bits to compute the old state, so if
it's inaccurate it might cause styles to be incorrectly invalidated.
This causes issues because with the next patch the autofill jsm
calls removeManuallyManagedStates(AUTOFILL), then
addManuallyManagedStates(AUTOFILL | AUTOFILL_PREVIEW), and if the input
didn't have AUTOFILL before we'd incorrectly detect it as not changing
with the next patch.
Also make them not virtual anymore since nobody overrides them. An
alternative to this would be to assert that we don't yet have the state
we're adding (or that we have the state we're removing), and handle it
in the callers. But this is a bit more convenient.
Differential Revision: https://phabricator.services.mozilla.com/D122013
The style system uses the changed bits to compute the old state, so if
it's inaccurate it might cause styles to be incorrectly invalidated.
This causes issues because with the next patch the autofill jsm
calls removeManuallyManagedStates(AUTOFILL), then
addManuallyManagedStates(AUTOFILL | AUTOFILL_PREVIEW), and if the input
didn't have AUTOFILL before we'd incorrectly detect it as not changing
with the next patch.
Also make them not virtual anymore since nobody overrides them. An
alternative to this would be to assert that we don't yet have the state
we're adding (or that we have the state we're removing), and handle it
in the callers. But this is a bit more convenient.
Differential Revision: https://phabricator.services.mozilla.com/D122013
If middle button click with `Shift` key occurs, Chrome and Safari extend the
selection in most cases. However, if the clicked position is in a link,
Chrome does:
* If editable, collapse selection into the link instead of extending selection.
* If not editable, not extending selection and open tabs.
We should follow this behavior for both backward compatibility and web-compat.
Differential Revision: https://phabricator.services.mozilla.com/D119252
XUL is different. According to bug 564863 comment 17:
> nsXULElement used to not call its superclass BindToTree to avoid this
> reparsing.
Presumably for perf reasons? But since then we've added the MayHaveStyle
flag, which should make it fast. I don't see any reason this special
case makes any sense.
I could write a test for this patch (parse a XUL element in a data doc
with a style attribute, import it into a regular document), but honestly
this is well covered by WPT for all other elements, and this is removing
code, so I don't feel it buys us much.
Differential Revision: https://phabricator.services.mozilla.com/D113015
I'm not sure whether we should deal with ancestor scales and such. There
seemed to be a discussion about that in D77436 but dealing with
partially-3d-transformed content sounds like a massive pain. For now
this fixes the start point, which is a progression.
Differential Revision: https://phabricator.services.mozilla.com/D106896
This makes the naming more consistent with other functions called
Insert and/or Update. Also, it removes the ambiguity whether
Put expects that an entry already exists or not, in particular because
it differed from nsTHashtable::PutEntry in that regard.
Differential Revision: https://phabricator.services.mozilla.com/D105473
Much like devtools manages the existing stylesheet changed events.
This is tested by devtools/client/inspector/markup/test/browser_markup_shadowdom.js
Differential Revision: https://phabricator.services.mozilla.com/D102875
This patch is generated via the rename functionality in my editor; add
`mozilla::` prefix to `OverflowAreas` in headers; and remove the
`OverflowType` alias added in Part 1.
Differential Revision: https://phabricator.services.mozilla.com/D97235
Actually software keyboard is opened by the following situations.
- Click event in editor
- Get new focus event.
Ace editor has small <textarea> element to handles some input events.
When clicking editable-like area (but this isn't ediable on Ace editor),
mousedown handler calls `event.preventDefault()` then set focus to
<textarea> element. So editor doesn't get click event and focus is still
keep in <textarea> element. At finally, we cannot open software keyboard
again since focus isn't changed.
So even if focus isn't changed, we should call SetInputContext to open
software keyboard.
Also, actually we doesn't have generic test code for notification of
software keyboard change (bug 1670539). I will add the test by bug 1670539.
Differential Revision: https://phabricator.services.mozilla.com/D93326
This ensures that styles from UA widgets apply. Turns out they look
pretty much right without them, but there's a bug in nsDateTimeBoxFrame
where we rely on the styles in order for the baseline to be sensible.
Differential Revision: https://phabricator.services.mozilla.com/D91616
This ensures that styles from UA widgets apply. Turns out they look
pretty much right without them, but there's a bug in nsDateTimeBoxFrame
where we rely on the styles in order for the baseline to be sensible.
Differential Revision: https://phabricator.services.mozilla.com/D91616
Changes to nsIScrollableFrame.h cause the world to rebuild which I find annoying.
This removes the inclusion into Element.h which is responsible for the
world-rebuilding and is relatively easy to eliminate. A bunch of usages of
nsIScrollableFrame get moved from .h files into .cpp files and I include the
header into .cpp files as needed.
Differential Revision: https://phabricator.services.mozilla.com/D90735
