Closed Bug 1429027 Opened 2 years ago Closed 2 years ago

Caret disappears when focused by TAB

Categories

(Core :: Web Painting, defect, P2)

57 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla59
Tracking Status
firefox59 --- verified
firefox60 --- verified

People

(Reporter: leyyyyy, Assigned: miko)

References

()

Details

Attachments

(2 files)

Attached image Bug.png
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20180103231032

Steps to reproduce:

Steps are described in attached image.


Actual results:

Caret is not displayed when input is focused.


Expected results:

Caret should be displayed when input is focused.
Component: Untriaged → Developer Tools: Console
It is not issue of Console.
It is issue of input element and can be reproduced by JS.
Console is used just for demonstration.
I reproduce as well, but only using the console (i.e. having a script that does all the different parts results in the text field being focused with a blinking caret).

Maxim, do you reproduce without using the console to set the input value ?
Flags: needinfo?(leyyyyy)
--Maxim, do you reproduce without using the console to set the input value ?

Yes, I initially did it with JS (during application development).
And only after that I have made some showcase with console.
I cannot put code here because I cannot trim it enough good (it is Bridge.NET).
But you can try set empty string in onchange event, for example I am doing that in some cases if input is wrong.
Flags: needinfo?(leyyyyy)
Thanks Maxim, I put up https://shift-tab-input-emptied-by-js.glitch.me/ which demonstrates the issue.
The is reproducible on Firefox 59 as well, on OSX.

Could you tell us which platform are you on Maxim ? It might be OSX only.
Better Steps to reproduce:
1. Go to https://shift-tab-input-emptied-by-js.glitch.me/
2. Don't do anything until the input is empty and focused again


Expected results:

We should see a blinking caret in the text input

Actual results:

The caret blink once (not always) and then do not blink anymore, unless you hover the input.



Maxim, can you confirm these steps lead to the bug ?

---

Also, I'm not sure if this is the right component to file this bug under. Feel free to move it elsewhere more appropriated.
Component: Developer Tools: Console → DOM: Core & HTML
Product: Firefox → Core
I can see the bug (actual result listed in comment 5) on windows 7 latest nightly.
Win 7 x64 59 Nightly has the same issue.

I assume it can be any element instead of select - input needs just to lose focus.
(In reply to Maxim from comment #7)
> Win 7 x64 59 Nightly has the same issue.
> 
> I assume it can be any element instead of select - input needs just to lose
> focus.

Right, I removed the select element and just blurred the input, this shows the issue as well. Thanks Flore and Maxim !
Nicolas, you don't happen to have mozregression set up so that we could get a regression range?
Flags: needinfo?(nchevobbe)
I do have it, but can't tell an initial "good revision".
Let me see what I can do with that.
Flags: needinfo?(nchevobbe)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Has Regression Range: --- → yes
Moving it to Web Painting. Matt, could you take a look?
Component: DOM: Core & HTML → Layout: Web Painting
Flags: needinfo?(matt.woodrow)
Blocks: 1352499
Priority: -- → P2
I can reproduce this on macOS with the latest Nightly.
Assignee: nobody → mikokm
Status: NEW → ASSIGNED
Flags: needinfo?(matt.woodrow)
Comment on attachment 8944040 [details]
Bug 1429027 - Include caret area for caret frames when calculating dirty region for retained display list

https://reviewboard.mozilla.org/r/214370/#review220066
Attachment #8944040 - Flags: review?(matt.woodrow) → review+
Pushed by mikokm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/e41964b766df
Include caret area for caret frames when calculating dirty region for retained display list r=mattwoodrow
https://hg.mozilla.org/mozilla-central/rev/e41964b766df
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
Duplicate of this bug: 1426348
I managed to reproduce the bug on an older version of Nightly (2017-01-09) on Windows 10 x64 using the link from comment 4.
I retested everything on latest Nightly 60.0a1 and beta 59.0b6 using Windows 10 x64, Ubuntu 16.04 x64 and macOS 10.13 and the bug is not reproducing anymore.
Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.