Open Bug 1587966 Opened 5 years ago Updated 2 years ago

Cursor does not appear if element is focused before being made contenteditable

Categories

(Core :: DOM: Editor, defect, P3)

69 Branch
defect

Tracking

()

Tracking Status
firefox71 --- affected

People

(Reporter: adam, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [h2review-noted])

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36

Steps to reproduce:

Follow the steps in the fiddle: https://jsfiddle.net/39umo4dn/73/

Click into an element which becomes contenteditable after the click.
Click into another element which becomes contenteditable after the click.

Actual results:

The cursor does not appear in the second element.

Expected results:

The cursor should appear in the second element and it should be editable like in Chrome.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Editor
Product: Firefox → Core
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
Webcompat Priority: --- → ?

(ni? myself to talk about this being important for Coda during triage)

Flags: needinfo?(miket)

It's interesting to note that in the linked jsfiddle, after you click on the second or third paragraphs, if you go back to them (once they've already had focus) the cursor is visible as expected.

Webcompat Priority: ? → revisit
Flags: needinfo?(miket)
Whiteboard: [h2review-noted]

I have a similar problem as can be seen with https://jsfiddle.net/pL1e8uro/1/ . In my case the issue seems to be caused by a mix of:

  • having a nested editable
  • focusing before make editable

And indeed, clicking outside (blur) and then back in (re-focus) fixes the problem (the caret becomes visible).

Severity: normal → S3
Webcompat Priority: revisit → ---
You need to log in before you can comment on or make changes to this bug.