Closed Bug 1932800 Opened 1 year ago Closed 1 year ago

Caret on many text fields (E.g. address-bar, b.m.o search field, etc.) appears to be shifted upwards

Categories

(Core :: Layout: Scrolling and Overflow, defect)

defect

Tracking

()

RESOLVED FIXED
134 Branch
Tracking Status
firefox-esr128 --- unaffected
firefox132 --- unaffected
firefox133 --- unaffected
firefox134 blocking fixed

People

(Reporter: mayankleoboy1, Assigned: emilio)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression)

Attachments

(5 files)

STR1
Create new profile
Click on the address-bar

AR: The mouse-cursor appears to be shifted upwards
ER: Not so

STR2
Click on the search-bar at the top of b.m.o
AR: cursor appears shifted upwards

Bisection:
Bug 1931466: Ensure inline elements inside an empty line has zero block-size and no baseline in scrolled block frames. r=layout-reviewers,dholbert
Differential Revision: https://phabricator.services.mozilla.com/D229709

Flags: needinfo?(dshin)
Attached file about:support

Set release status flags based on info from the regressing bug 1931466

I can confirm the issue.
The caret(text insertion point) is shifted upwards if the input field is empty.
STR:
1 open data:text/html,<input autofocus>

Summary: Mouse cursor on many text fields (E.g. address-bar, b.m.o search field, etc.) appears to be shifted upwards → Caret on many text fields (E.g. address-bar, b.m.o search field, etc.) appears to be shifted upwards
Duplicate of this bug: 1932812

[Tracking Requested - why for this release]: Obvious UI visual regressions to the caret in text fields.

Tracking for 134

Duplicate of this bug: 1932821
See Also: → 1932840
Assignee: nobody → emilio
Flags: needinfo?(dshin)

This was already kind of an issue before, apparently: data:text/html,<div contenteditable autofocus><span>

Duplicate of this bug: 1932847

Setting it as a 134 blocker as it impacts most websites with forms and the regression is visible.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)

This was already kind of an issue before, apparently: data:text/html,<div contenteditable autofocus><span>

Sorry off-topic but in comment#8 case,

Regression window in comment#8 is as follows:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2f45c30741c5&tochange=422bbd8245a7
Suspect: db8e95fbcd39b56b7ae7ad0877e774f9e046949b 	Ehsan Akhgari — Bug 644428 - Position the caret correctly for empty inline frames; r=roc

(This also affects the address bar)

Added Gecko reftests because I don't know what the best place to put
them in WPT is, and caret rendering is kind of undefined, but...

(Added two more crash bugs as blocks because they look related)

Blocks: 1932796, 1932752
No longer blocks: 1932796

This is similar to how we treat <div contenteditable>, and allows us to
remove the specialness about anon boxes.

All the callers check both conditions, so no behavior change.

We were relying on editable text frames not being empty. We fixed that
on the previous patches but this caused editor d&d to break.

For now this preserves the selection behavior. In the future we should
look into removing the IsEmpty() condition or so, probably, or make it
more subtle.

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/6f6758d53d7f Fold IsEmpty check into SelfIsSelectable(). r=dshin

Updated try runs:

Keywords: leave-open

The IsEmpty special-cases begin in bug 316281. It's not clear to me why they are needed.

That's only mentioned in bug 316281 comment 23. Will try to remove in a separate bug.

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ee6527afae3b Add a check to SelfIsSelectable to preserve editor drag and drop behavior. r=masayuki
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/333442d03d1a Fix caret baseline of empty inline and text frames. r=dshin https://hg.mozilla.org/integration/autoland/rev/048956318eb0 Use ShouldHaveLineIfEmpty() to guarantee buttons have at least one line of height. r=dshin https://hg.mozilla.org/integration/autoland/rev/c06b939ca2f2 apply code formatting via Lando

You pushed the last patch, should leave-open be removed now?

Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/4974ccf274fa Fix caret baseline of empty inline and text frames. r=dshin https://hg.mozilla.org/integration/autoland/rev/7cda61151052 Use ShouldHaveLineIfEmpty() to guarantee buttons have at least one line of height. r=dshin https://hg.mozilla.org/integration/autoland/rev/f40a44add850 apply code formatting via Lando
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/a47e016449ef Fix reftest-snapshot annotations, and one AccessibleCaret test.
Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(emilio)
Resolution: --- → FIXED

Hi! Your push causes marionette perma failures. Could you take a look?

Flags: needinfo?(emilio)

Backed out for causing marionette perma failures @test_accessiblecaret_cursor_mode.py.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #9439360 - Attachment description: Bug 1932800 - Fix caret baseline of empty inline and text frames. r=dshin,jfkthame → Bug 1932800 - Fix caret baseline of empty inline and text frames. r=dshin
Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b0a2ef9d7ae3 Fix caret baseline of empty inline and text frames. r=dshin https://hg.mozilla.org/integration/autoland/rev/93a86915295b Use ShouldHaveLineIfEmpty() to guarantee buttons have at least one line of height. r=dshin
Status: REOPENED → RESOLVED
Closed: 1 year ago1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 134 Branch

Add a check to SelfIsSelectable to preserve editor drag and drop behavior. r=masayuki
https://hg.mozilla.org/mozilla-central/rev/ee6527afae3b

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: