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.
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 ?
--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.
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.
Has STR: --- → yes
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?
I do have it, but can't tell an initial "good revision". Let me see what I can do with that.
mozregression is finished, pointing to : https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7fb001f811d183095e9cfdd958c9215484377396&tochange=d5e1ed773fefe2eb9d52402dd74b5fea19b8b4a4 . Might be related to retained list I guess (really not sure)
Moving it to Web Painting. Matt, could you take a look?
Component: DOM: Core & HTML → Layout: Web Painting
I can reproduce this on macOS with the latest Nightly.
Assignee: nobody → mikokm
Status: NEW → ASSIGNED
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 firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/e41964b766df Include caret area for caret frames when calculating dirty region for retained display list r=mattwoodrow
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.
You need to log in before you can comment on or make changes to this bug.