Open Bug 226301 Opened 21 years ago Updated 1 year ago

text cursor disappears sporadically with css scale down

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
x86
Windows
Type:
defect

Tracking

()

People

(Reporter: mozilla+bugzilla, Unassigned)

References

Details

Attachments

(2 files)

Testcase shows how the caret is rendered incorrectly
2.43 KB, application/x-zip-compressed
Details
simple testcase
465 bytes, text/html
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Sometimes cursor disappers during editing text (esp. in the textareas). I can edit still, but just don't see the blinking | Reproducible: Sometimes Steps to Reproduce:
without specific steps to reproduce, this bug is of no value. I'm unable to reproduce a disappearing cursor in any of the text fields on this page. worksforme with 20040425 Firefox on winXP
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Reopening bug, per Doug Ledbetter request. He has some comments.
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I've had this problem with FireFox for a LONG time and it still exists in the v1.0 release. I answer customer service questions via a web-based ticketing system all day long. When I'm typing and editing my response in textarea fields, the text cursor often disappers which is very frustrating. Unfortunately, this page isn't a publically available resource. I'll do some more testing and see if I can come up with a set of steps that will reproduce this bug. It may be related to a Javascript function. -dougl
I have created a short screen capture video of the disappearing cursor in Firefox version 1.0 at the following URL: http://www.dougledbetter.org/downloads/Firefox_cursor_disappears.avi It's not too big (~900KB). This video is of me editing text in a textarea field. You'll notice that the cursor seems to always disappear at particular points in the text as I'm moving around using the keyboard arrow keys so that when the problem occurs, you can re-create it over and over at particular points in the text. Unfortunately, this happens for me a LOT and causes a lot of headaches. Please let me know what else I need to provide to help track down this bug. Do you need to see the JavaScript functions that are on this page? -dougl
It seems this bug has been neglected... ...That video does show how certain areas of the text don't let the cursor be seen. If you can, can a testcase be created that narrows down the cause? You said it is not a public page, so I will refer you to where you can make the best testcase possible: http://www.mozilla.org/newlayout/bugathon.html With a testcase, it will be much easier to identify the bug and get it fixed for you. --Someone with permissions, or the reporter needs to add the keyword "qawanted" to this report so a testcase can be created for this bug.--
Keywords: qawanted
How about providing an URL showing this issue?
Not sure whether this is the same bug, but here is a way to reproduce this reliably: 1. Go to http://episteme.arstechnica.com/eve/ubb.x and choose a random sub forum and thread. 2. Hit the reply button at the bottom right of the page. 3. Add a smiley by using the smiley button above the textarea. 4. Zap, the cursor is gone. Just tested again on Firefox 1.0 and Mozilla 1.8a6.
Here is the same bug, or a similar one: http://flarb.net/disappearing_cursor_bug.html A hidden div blocks the cursor from showing, but not anything else.
*** Bug 278366 has been marked as a duplicate of this bug. ***
Assignee: firefox → roc
Component: General → Layout: View Rendering
Depends on: 226933
Product: Firefox → Core
QA Contact: ian
Version: unspecified → Trunk
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Could be fixed by bug 287813.
Depends on: 287813
Bug 287813 is fixed now. Reporter, maybe you would like to try the latest trunk build to see whether this bug is still there?
I've using Firefox 1.5.x and haven't seen this bug for a while... Maybe Doug Ledbetter can try.
It's been a long time since the last comment (dated 2006-04-19) and I still see the bug from time to time...I'll be typing in a text box and the cursor will disappear. Anyone else still see it?
At this point we only care if someone sees it on trunk. If you're still using Firefox 2 you don't have our fix for bug 287813.
I still see it in 3.0 Nightly Trunk but it's rare. My mistake for not giving information as to what build I use.
I see this on the trunk fairly frequently (I only ever run the trunk). I have not yet been able to determine what sequence of operations causes it, or what sequence fixes it.
I just got it in Gmail's standard editor. Let's not forget about this bug. It's not critical, but still very annoying and would be a major help to the Firefox experience when fixed. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091104 Minefield/3.0a8pre ID:2007091104
Peter, if you could give some way of reproducing this bug, that would be very helpful.
I honestly have no idea how it happens. I'll just be typing along and it'll disappear. It happens a lot more rare now than in older builds (such as those from year 2006.) To be honest, it's one of those bugs I totally forget about unless it happens. I'm not entirely sure, but it may have something to do with the amount of RAM and the number of programs I have running. .. the more programs I have running, the more likely it is to disappear??
Happens to me multiple times daily in trunk builds. The workaround is to select another window and then select the window I'm trying to work in, again. I do that without thinking about it now, because I do it so frequently. :-(
It happened just now in Blogger.com while replying to a blog entry. I was using arrow keys to move up a few rows. I think I had "background" activity on my computer at that same time... Like I said before, the more programs I have running, the more likely it is to disappear?? workaround: Click outside text box, then click back in it. I'd love to see this bug be fixed, but since it can't be reproduced easily... Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007092305 Minefield/3.0a9pre ID:2007092305 Adblock Plus 0.7.5.2 BugMeNot 1.3 [DISABLED] DOM Inspector 1.9a9pre Google Images Re-Linker 0.4 [DISABLED] IE Tab 1.3.3.20070528 Nightly Tester Tools 1.3b3 Splash 1.2.2 Throbber Button 0.9 WebmailCompose 0.6.5 [DISABLED]
i dont know if it can help but.. windows xp has an option to hide the mouse pointer when youre typing, try to turn off this option: control panel > mouse > 3rd tab(pointer options or something like that, im not sure because im not using english windows) > unmark the option: hide pointer when typing
"windows xp has an option to hide the mouse pointer" Aren't the mouse pointer and the cursor two specifically different things? I don't see how changing the mouse pointer settings would affect the cursor. For the record, my "hide pointer when typing" box is checked.
sorry i didnt fully read the first comment, now i understand the problem, and thinking about it, it never has happened to me
This bug is probably one of the most sporadic, randomly-appearing bugs in Minefield. It JUST came up, quoting a post on an online web forum. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008040606 Minefield/3.0pre ID:2008040606Adblock Plus 0.7.5.3+.2008040612 BugMeNot 1.3 Google Images Re-Linker 0.4 IE Tab 1.5.20080310 Mail2:Webmail 1.0 Nightly Tester Tools 1.3 Splash 2.0.0.1 Throbber Button 0.9 WebmailCompose 0.6.5 [DISABLED]
This was tested with Firefox 2.0.0.14 on Windows Vista SP 1. After some time and clicking in other tabs/windows the caret show correctly.
I've been having this problem for what seems like forever now. And it only happens in Firefox, so I am currently using IE7 to type this, so I won't have to redo it over and over and over again because the flippant disappearing Cursor coupled with the new backspace function (or error) was driving me insane. It to me seems like a buffer problem of a sort. When I type slow, all goes fine, until the cursor turns into the hour glass or just disappears entirely. Sometimes if I wait a few seconds, the cursor re-appears, and I can re-click on where it disappearred so I can get the flashing prompt, "|", again to continue typing. Other times, when I'm in a rush, and type at my normal speed or faster, the flashing prompt, "|" disappears alot more, while the cursor turns into the hour glass rotating, or disappears entirely. Jiggling the mouse was common practice when we all used ball type mice before laser and optical mice came along. But since using Firefox I find myself jiggling my optical laser mouse like if it were an old ball mouse :( And the newest annoyance is when I mistype because of the disappearing prompt "|", and I end of entering the wrong text, and hit the backspace key while its in a, "rotating hour glass", or "missing flash prompt", mode, hitting the backspace key is like hitting the back button (back/forward browser buttons) so it undo's or goes back one page, erasing everything I had done on the previous page. This is hardly what I would call a minor problem. FireFox should make this a top priority because if people can't type while using Firefox, what would be the point of anyone using them at all? ...considerring I'm using IE atm to even type this, because of having all this ranting of mine erased several times using Firefox was enough to make me throw myself off my balconey ... I live on the 45th floor. !!!!!
David, useless hyperbole aside, what this bug needs more than anything else right now are concrete steps to reproduce it. Nobody's questioning whether or not people are truly experiencing the issue, but if the people who understand the relevant carat code can't reproduce it themselves, it's next to impossible for them to be able to fix it. Personally to me, it sounds like a focus issue more than anything else.
Hmm, all I know is I have Speed Dial installed as my home page, and its set to refresh its contents on some links every 30s to 300s (I use it to keep track of several e-mail accounts). Though the Speed Dial page isn't open in any tab or any window, I noticed and timed the frequency the mouse cursor disappearred or went into a busy state was the exact schedule of the Speed Dial settings. So I have disabled all my Speed Dial settings to keep the cursor from going into a busy, or missing state til this problem is defined and fixed. Any plugin that requires background work seems to put the mouse cursor/ prompt cursor into this busy/missing state. As an additional note, this problem only seems to effect single processor cpu's alot more if I am not mistaken. I have a P4 2.43b as well as a dual core (AMD Athlon), as well as a quad core (AMD Turion) computer. On the quad core I have rarely seen this problem - it only happened once - On the dual core it happens at least once a day, and on the P4 every fricken minute >:(
I agree it's probably a focus issue, but not having a reliable test case doesn't make it easy to debug.
Well, I'm new to this forum and I can fully testify that this IS the most random bug. The cursor just lost focus right there! Been ongoing for me for the last year or so...it happens in comments/text area boxes like these. The cursor will disappear, and then turn to an hour glass and lose focus until I click back inside the box. This happened even before I installed the Weave extension. The extensions I have are: IETab Autoclose Bookmarks Dictionary lookup mailman toolbar forecast fox greasemonkey FireFTP Now, you see...my cursor hasn't disappeared since the beginning of the second sentence of this message!
It all breaks down to processor power, and how many add-ons you have installed. I'm using a P4 2.4 with 1G of ram, and currently running 15+ add-ons and this focusing problem only seems to effect low ram/low processor power people. Those with dual core or higher will never experience this problem. My room has a dual core and has never come across this problem. My quad core at work has never seen this problem either... just my lowly ancient single core processor. :(
room = roomie..... bad typo :P
(In reply to comment #34) > It all breaks down to processor power, and how many add-ons you have installed. > I'm using a P4 2.4 with 1G of ram, and currently running 15+ add-ons and this > focusing problem only seems to effect low ram/low processor power people. > Those with dual core or higher will never experience this problem. My room has > a dual core and has never come across this problem. My quad core at work has > never seen this problem either... just my lowly ancient single core processor. > :( > Well, I'm sorry to burst your theory...but, I doubt anyone in here has a slow processor since (if i must admit myself) this is geek city! Hahah! C'mon, it's true...btw, I'm running quad at the house and dual at work. Problems in both places.
Jason, this is not a public discussion forum. This is a bug tracker. This bug is already littered with comments that don't help in resolving this bug. Please don't add more as it just makes it harder to find the relevant information needed to solve the bug. If you want to chat about this, do it on the newsgroups or on the forums. https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
I'm not chatting, I'm just describing to the best of my knowledge of how to recreate this problem so maybe someone with a similar setup can debug or understand the focusing issue here. But since my theory was just shot down, perhaps someone else can input what they had running in the back ground when this, 'focus' issue happens.
David, are you using Firefox 3? if you're using Firefox 2, then it's not really relevant (because development on that branch has stopped, for the most part).
(In reply to comment #39) > David, are you using Firefox 3? if you're using Firefox 2, then it's not really > relevant (because development on that branch has stopped, for the most part). > I'm using 3.0.1, and as each version/update comes out, the problem is still there on all my computers (single to quad processors). So it tells you that this problem is deep rooted in FF1-3 and until they figure out what is causing it to loose focus or whatever may be causing this bug, no new update or newer versions will fix it. And besides, I can read, and have read that the development on that branch regarding ver. 2.0 has been halted thank-you very much. Gee I love morons who talk down to me, assuming they know more than I do, when I can probably dance circles around them. (I do apologize to Ryan Vandermeulen and others for adding the closing statement that turns this simple reporting post of mine into a forum type message)
Sorry, I didn't mean to talk down on you, just wanted to be sure. Fwiw, there was a caret rewrite (in bug 287813) that's in Firefox 3, so the current "disappearing caret" problem in Firefox 3 might have a completely different cause as in Firefox 2. Steps to reproduce are desperately needed.
The odd thing here, is we who have run into this problem each have a different method or reason why this happens, and that right there tells you, it may not be as simple as a, "focusing", problem as it has been labeled. Which was my point in the first place. For me, turning off background add-on updating or refreshing has alleviated most of my, "focus", problem but its still there, and ever so annoying regardless of which update/version I am using.
The only way that I can think of recreating this issue is to open your browser...visit a few websites, leave it idle for a couple of minutes, then try typing into the search field in firefox in the upper right of the browser. type as many characters as it takes - I used the ~~~~~~~~~~!!!!!!!!!!! characters myself. OR, you can try typing in a form field to try to make the cursor lose focus, along with firefox all together. The reason I say this is because if you try to use the middle mouse wheel, you won't be able to scroll the page unless you click the page to regain firefox's focus - then you're back where you were suppose to be in the first place, with firefox in focus :)
I just finished watching a long clip in firefox and firefox kept knocking me off from full screen at intermittent intervals. However, it started at around 23-25 minutes into the show and it came out of full screen mode. I can't express enough how random this is. But, it's one of the most annoying bugs. I looked in the error console and this is what I'm getting for: Messages: Deprecated method document.getSelection() called. Please use window.getSelection() instead. **Not sure if that helps, but that's pretty much all that was in there.
I must be confused, because I fail to see the connection between being knocked out of full-screen is related to the blinking | disappearing while typing text.
I have seemed to have made peace with my disappearing caret/focusing issue by removing/disabling addons which have alot of background activity. The only thing I can suggest to those who are trying to debug this problem is to get the, "speeddial", addon and load in atleast two full pages (3x3 each) of websites speed dials to refresh at 1 minute intervals each, then go do webmail. I still use Speed Dial, but I no longer have it refreshing each site every 5-10 mins (very useful to keep track of several e-mail accounts or other type of need-updated-info type of websites). It was quite easy to reproduce this problem using the, "Speed Dial", addon with atleast 2 full pages of 9 sites refreshing at 1 minute intervals. If that doesn't work, keep adding pages into Speed Dial, and have those new pages all refreshing their content at 1 minute intervals, until the problem occurs. On the single processor it only takes 2 pages of 9 sites to reproduce this problem, on the dual core it took 5 pages of 9 sites, and on the quadcore I have 10 pages loaded and only had the focus/caret problem when I had another application running in the background (video conversion) while doing webmail.
My issue was with MailMan. Every time this addon goes to check my mail servers for new messages, my cursor loses focus. I noticed that whenever I increased the increments on the times for it to check for new mail, it would happen less often. Hence, an addon problem.
But because this seems to happen with alot of different addons, wouldn't the problem simply be just a caret focusing problem? Each time it happens I load up the error console, but there is nothing in there to explain how it lost focus. How do we (I), take a look into what processes or scripts are being executed, at any particular time?
Still happening. I left Minefield open for quite a while while downloading Windows updates (thanks to IE Tab), then I went to another website and it disappeared. Also interesting is that over the past build or so, it seems like i've lost the ability to click in textboxes in order to input text. Could either, or both of these be processing-power issues? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090530 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090530044023
QA Contact: ian → layout.view-rendering
My memory useage in firefox.exe is up to 189,000 K. My "commit charge" is 565M/3431M. Anyone else still seeing this? Anyone else think it's related to memory use?
(In reply to comment #1) > without specific steps to reproduce, this bug is of no value. I'm unable to > reproduce a disappearing cursor in any of the text fields on this page. > worksforme with 20040425 Firefox on winXP Try facebook.com for example (reproduceable: always when adding comment on existing messages)
According to bug 657956 comment 8 this might be fixed in Fx 8 nightly. Anyone who can reproduce this, please test! http://nightly.mozilla.org/
Blocks: 657956
Mine (version 6) does the same thing - cursor sporadically disappears. I can still point the arrow cursor and click and continue editing from where I clicked, but the cursor refuses to come back. I have no idea how to reproduce it - it's very sporadic. This bug has been there since at least, version 3. Opening a new email allows the cursor to return.
> Mine (version 6) does the same thing Please test with Firefox 8 (currently Beta) http://www.mozilla.org/en-US/firefox/channel/
Answering request in comment 54: Still a problem here with Firefox 8.0. I have no shortage of CPU power or memory, so that shouldn't be an issue. I've had the problem for many years across many Firefox versions. It happened again to me a few minutes ago while using the reply text form at physicsforums.com.
And it even happens in the "Write email" window of Thunderbird 8.0.
In my experience it can happen in any text input area. It appears to depend on which two text characters are either side of where the cursor should be. Not always the same character pairs cause the cursor to disappear - that appears to depend on font and font size and on whether and by how much the display has been "zoomed" using CTRL+. I have also noticed, and wondered whether it is connected, that when the display is zoomed using CTRL+ the horizontal position of the cursor at some zoom levels is incorrect. The error is greater the more characters to the right the cursor is positioned. The error can be as little as a part character and as much as several characters. I can invoke these effects at will on two completely different PCs, one using FF 3.6.6 and the other using FF 8.0. Both running openSuSE 11.3. My font (and most other) settings in FF are default. I hope that this is useful to a developer willing to investigate and fix (I am not a developer). I believe that this bug should have a higher priority than minor. I love FF but this is almost enough of a use hindrance to make me look to use something else.
Confirm that cursor randomly disappears in comboxes on W/8 64 bit on brand new PC (ASRock 970 Extreme 3 mobo; AMD 6350 3.9 ghz; 8gb ram) but which it did not do on the same site (Free Republic) using W/8 on a different PC, both with the same FF configuration. No errors seen at this time in Event Viewer.
Dropping qawanted based on comment 28.
Keywords: qawanted
The cursor is intermittently disappearing as I enter text into a text boxes on certain websites. While entering this comment, I noticed it works just fine here. I can't remember what other places this happens at, but I know it happens to me frequently at asana.com. When I try to edit task descriptions, the cursor sporadically disappears. I am using Firefox 39.0 on Linux Mint 17.1.
(In reply to still_dreaming_1 from comment #61) > The cursor is intermittently disappearing as I enter text into a text boxes > on certain websites. While entering this comment, I noticed it works just > fine here. I can't remember what other places this happens at, but I know it > happens to me frequently at asana.com. When I try to edit task descriptions, > the cursor sporadically disappears. I am using Firefox 39.0 on Linux Mint > 17.1. Should I submit a new bug report for this for Linux Mint since this one if for Windows XP?
I am suddenly having this problem, seemingly for the first time, on a fairly consistent basis when drafting/editing emails in the Seamonkey email client.
This seems to still (!) be an issue. I don't see anyone posting a repro, so here's a small repro. Tested on 45.0.1. Open this HTML in FireFox, type some text (my test text was "the end"), and move your cursor around the text. You should see it appear and disappear. You can play with the font-size, font-weight, and transform values, and the cursor will appear or disappear in different points in the text depending on what values you put there. <html> <head> <style> .test{ font-size: 66px; font-weight: 900; transform: scale(0.5, 0.5); } </style> </head> <body> <input class="test" /> </body> </html>
I've seen this issue on windows 7 using FF 45.0.2. Steps to reproduce: Here is the HTML I am using: <html> <head></head> <body> <textarea style="width: 300px; height: 150px;"></textarea> </body> </html> Using the IME Keypad enter several lines of Pinyin text into the text area. Press Ctrl-Z to undo several lines. Press Ctrl-Y to redo. On redo the caret disappears.
This bug (at least it is this symptom manifests itself on a regular basis in the edit boxes on SUMO. It is a fairly poor reflection on Firefox when it's own support site does not work correctly using Firefox, but works fine in the competitors browsers. I have modified the operating system to Windows as I have experienced this in Windows XP, Windows 7 and Windows 10 over some 45 versions of Firefox.
Severity: minor → normal
OS: Windows XP → Windows
I've found a way to make the cursor reappear without restarting the browser: you should turn Caret Browsing on and off (use F7)
(In reply to forkest from comment #67) > I've found a way to make the cursor reappear without restarting the browser: > you should turn Caret Browsing on and off (use F7) This worked for me. It's curious why this would need to be pressed, though, as I just rebooted my computer, and never errantly hit that key, so I never accidentally had F7 off to begin with.
This error now exists for many years. It can be easly reproduced by typing text in any textarea, input or contenteditable area with an element css transform:scale(x) and x<1. Simple use the search input at the top of this page, set element style to transform:scale(0.77) via inspector and type some text. In my case the cursor disappears after 5 'a' or 6 '1' This effect is similar to a resized grid without resampling: some lines disappear due to subpixel width
Cursor disappears: I use Windows 7 Pro and am using Firefox 50.0, and Mozilla Thunderbird 45.5.0. I happen to have a second monitor established so I can work optionally on either screen. However, the situation I am about to describe is independent of this setup, since I am basically just working on my ‘prime’ monitor, not jumping back and forth at all as I work: focused on the writing task at hand, such as typing up this description. I HAVE read the “Bug Writing Guidelines” procedure for submitting bug reports... My problem is that if I am typing away for some period of time, maybe a few minutes, maybe a bit longer, I go to use the mouse finally (to save my work, or perhaps to look for something on my desktop) I move the mouse - and no cursor can be seen. I swipe and swirl to no effect, and since I have this option set up, I press a Ctrl key and - again, no telltale blink to see where the cursor happens to be located. I swirl again,press the Ctrl key - and I see nothing. The cursor seems to have disappeared! The question is, am I looking to Thunderbird for the solution, or Firefox? I don’t know, so maybe this is why there is a ‘bugzilla’ available, enabling me to address the Mozilla community directly and ask for help in resolving this problem. Now, I see that there has been a description of this problem for over ten years. I also note that the person asking for help has been requested to identify the circumstances surrounding the environment at the time the cursor disappeared. If most people (and I think I am an example of most people) don’t think much about something they take for granted, when something like this happens the question as to what I was doing is more general in nature and the specifics of being able to recreate the situation are difficult to describe (for most people). I don’t share the same terminology that technicians use, and sometimes a word or two used in a description has different meanings, resulting in different interpretations and confusion. 100 years ago, before there was a computer, we described our problems face to face with those we sought help from, and this became immediately impractical upon the web. We sought a better way to communicate, and when severe errors occurred someone developed the Ctrl-Alt-Delete solution to ‘halt everything - let’s take a look at this’. The problem with that solution in the case of the missing cursor is that the cursor stays hidden and one is forced to tab and watch for a highlighted button before pressing the enter key to take an option which is drastic and which does not allow either continuing or saving work-in-progress. I submit there is a need for a similar work-around, perhaps a ‘Ctrl-Shift-F5’, that would force the cursor to appear in the center of the current window. Nothing would be ‘hurt’ in this situation and once visible the cursor comes back into user control and (perhaps) a bug report can be sent identifying the occurrence and all technical stuff gathered that I (and most people) don’t know how to provide. In my world this is called a convention, and just as the Ctrl-Alt-Delete has a shared audience around the globe so too would the Ctrl-Shift-F5 become common knowledge. This might be a workaround but ten years is a long time to live with a ‘bug’ that cannot be defined adequately to resolve. Maybe the Ctrl-Shift-F5 would not be published, because who needs to identify the inability to resolve a problem? But that is just the point! If the problem occurs, Mozilla can suggest using the Ctrl-Shift-F5 sequence and the subsequent transfer back to Mozilla for system analysis purposes (while establishing the cursor in the center of the prime window) would help both sides, user and technicians, identify and resolve the problem. I don’t know enough to know how to accomplish what I’m suggesting, just as I don’t know enough to know how to resolve issues causing me to use the Ctrl-Alt-Delete approach. I suspect what I’ve described is feasible but I don’t know enough to be adamant about ir. I know it is also natural to resist change, to fight the inclusion of unnecessary code or procedures into something as substantial as Mozilla’s products. Finally, I know that in the absence of a proffered solution a complaint cannot be addressed. I am making this suggestion as a means of addressing my missing cursor problem. Maybe there is another way for me to locate the cursor, or an existing keystroke combination that already does what I am asking the Ctrl-Shift-F5 to do - present the location of the cursor or, if it has ‘slidden’ off the screen, center it and draw attention to it, similar to the Ctrl key option. Thankfully, the cursor has remained with me while I typed this description. While this is good for me, it doesn’t begin to explain why or how it disappears - it just does. And this goes back to trying to describe the circumstances present when the problem occurs... I’ve tried to incorporate a description of what I am doing hoping to see something that would allow me to ‘aha!’ but since that hasn’T happened, I share these thoughts with you. Thank you for your consideration.
(In reply to JBMoss from comment #70) > Cursor disappears: I use Windows 7 Pro and am using Firefox 50.0, and > Mozilla Thunderbird 45.5.0. I happen to have a second monitor established so > I can work optionally on either screen. However, the situation I am about to > describe is independent of this setup, since I am basically just working on > my ‘prime’ monitor, not jumping back and forth at all as I work: focused on > the writing task at hand, such as typing up this description. I HAVE read > the “Bug Writing Guidelines” procedure for submitting bug reports... > > My problem is that if I am typing away for some period of time, maybe a few > minutes, maybe a bit longer, I go to use the mouse finally (to save my work, > or perhaps to look for something on my desktop) I move the mouse - and no > cursor can be seen. I swipe and swirl to no effect, and since I have this > option set up, I press a Ctrl key and - again, no telltale blink to see > where the cursor happens to be located. I swirl again,press the Ctrl key - > and I see nothing. The cursor seems to have disappeared! > > The question is, am I looking to Thunderbird for the solution, or Firefox? I > don’t know, so maybe this is why there is a ‘bugzilla’ available, enabling > me to address the Mozilla community directly and ask for help in resolving > this problem. > > Now, I see that there has been a description of this problem for over ten > years. I also note that the person asking for help has been requested to > identify the circumstances surrounding the environment at the time the > cursor disappeared. If most people (and I think I am an example of most > people) don’t think much about something they take for granted, when > something like this happens the question as to what I was doing is more > general in nature and the specifics of being able to recreate the situation > are difficult to describe (for most people). I don’t share the same > terminology that technicians use, and sometimes a word or two used in a > description has different meanings, resulting in different interpretations > and confusion. > > 100 years ago, before there was a computer, we described our problems face > to face with those we sought help from, and this became immediately > impractical upon the web. We sought a better way to communicate, and when > severe errors occurred someone developed the Ctrl-Alt-Delete solution to > ‘halt everything - let’s take a look at this’. The problem with that > solution in the case of the missing cursor is that the cursor stays hidden > and one is forced to tab and watch for a highlighted button before pressing > the enter key to take an option which is drastic and which does not allow > either continuing or saving work-in-progress. > > I submit there is a need for a similar work-around, perhaps a > ‘Ctrl-Shift-F5’, that would force the cursor to appear in the center of the > current window. Nothing would be ‘hurt’ in this situation and once visible > the cursor comes back into user control and (perhaps) a bug report can be > sent identifying the occurrence and all technical stuff gathered that I (and > most people) don’t know how to provide. In my world this is called a > convention, and just as the Ctrl-Alt-Delete has a shared audience around the > globe so too would the Ctrl-Shift-F5 become common knowledge. This might be > a workaround but ten years is a long time to live with a ‘bug’ that cannot > be defined adequately to resolve. > > Maybe the Ctrl-Shift-F5 would not be published, because who needs to > identify the inability to resolve a problem? But that is just the point! If > the problem occurs, Mozilla can suggest using the Ctrl-Shift-F5 sequence and > the subsequent transfer back to Mozilla for system analysis purposes (while > establishing the cursor in the center of the prime window) would help both > sides, user and technicians, identify and resolve the problem. > > I don’t know enough to know how to accomplish what I’m suggesting, just as I > don’t know enough to know how to resolve issues causing me to use the > Ctrl-Alt-Delete approach. I suspect what I’ve described is feasible but I > don’t know enough to be adamant about ir. I know it is also natural to > resist change, to fight the inclusion of unnecessary code or procedures into > something as substantial as Mozilla’s products. Finally, I know that in the > absence of a proffered solution a complaint cannot be addressed. I am making > this suggestion as a means of addressing my missing cursor problem. Maybe > there is another way for me to locate the cursor, or an existing keystroke > combination that already does what I am asking the Ctrl-Shift-F5 to do - > present the location of the cursor or, if it has ‘slidden’ off the screen, > center it and draw attention to it, similar to the Ctrl key option. > > Thankfully, the cursor has remained with me while I typed this description. > While this is good for me, it doesn’t begin to explain why or how it > disappears - it just does. And this goes back to trying to describe the > circumstances present when the problem occurs... I’ve tried to incorporate a > description of what I am doing hoping to see something that would allow me > to ‘aha!’ but since that hasn’T happened, I share these thoughts with you. > Thank you for your consideration. BTW - this has NOTHING TO DO with Caret Browsing (F7). There is simply NO SIGN of a cursor, anywhere, when this vanishing cursor makes its move. When the cursor disappears. it is gone - poof.
I have experienced this bug for a while and I have now finally realized that I always lose the cursor after I drag and drop an attachment into the top RHS when composing an email. The condition persists until you shutdown Thunderbird and restart it.
See also "Cursor disappears when viewing page, does not return until browser is restarted." - https://bugzilla.mozilla.org/show_bug.cgi?id=720233
github.com: The text cursor hides when you click on "Insert a quote" - https://github.com/davidhedlund/Feedback-for-websites/issues/24
"As a workaround, if you minimize and restore the Firefox window, the cursor will return." - https://superuser.com/questions/833354/text-cursor-disappears-in-firefox
Component: Layout: View Rendering → Layout: Web Painting

I'm not able to reproduce this issue anymore. Particularly, inserting a quote on GitHub (comment 74) now shows the cursor correctly. Please reopen with a recent test case if this can still be reproduced. Thank you!

Status: NEW → RESOLVED
Closed: 20 years ago → 6 years ago
Resolution: --- → WORKSFORME

Cursor still disappears in textareas, inputs and *[contenteditable=true] if css transform scale is smaller than 1. Please see comment 69 for test case.

(In reply to Jo from comment #77)

Cursor still disappears in textareas, inputs and *[contenteditable=true] if css transform scale is smaller than 1. Please see comment 69 for test case.

Could you provide the version of Firefox and the OS you're seeing this on? I just tested in 64.0.2 on macOS 10.13.6 and I was unable to reproduce the issue. I realize that this bug was reported against Windows. I assumed that this was cross-platform since this bug was referenced from another macOS bug. It may be Windows specific, in which case I'm happy to reopen this bug. Thanks!

Flags: needinfo?(voss)

(In reply to Stephen A Pohl [:spohl] from comment #78)

(In reply to Jo from comment #77)

Cursor still disappears in textareas, inputs and *[contenteditable=true] if css transform scale is smaller than 1. Please see comment 69 for test case.

Could you provide the version of Firefox and the OS you're seeing this on? I just tested in 64.0.2 on macOS 10.13.6 and I was unable to reproduce the issue. I realize that this bug was reported against Windows. I assumed that this was cross-platform since this bug was referenced from another macOS bug. It may be Windows specific, in which case I'm happy to reopen this bug. Thanks!

The version is 64.0.2 on Windows 10 Version 1809

Flags: needinfo?(voss)

Thank you!

Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
Attached file simple testcase —

I have a testcase attached here, can anyone reproduce the bug with that?

(I can't with any scaling factor)

(In reply to j.j. from comment #81)

Created attachment 9039166 [details]
simple testcase

I have a testcase attached here, can anyone reproduce the bug with that?

(I can't with any scaling factor)
Yes, cursor disappears in textarea between characters "x" and "t" and in [contenteditable] after typing "divvvvv"

^ Same as Jo cursor also disappears between x and t after pasting "divvvvv".

I think this is a dupe of bug 1510942 which is fixed in Firefox 65. Can somebody confirm that?

No. In 66.0b2 (64-bit)[win10] the bug persists. In the testcase (#82) the cursor disappears in textarea between characters "e" and "x" and in [contenteditable] between "i" and "v" and after "v".

The bug is visible on different PCs.

I just now noticed this happening at https://intfiction.org/. Around half the time, the cursor will vanish while typing a new post or posting followup. It's not clear to me what I need to do to trigger it or exactly what to do to get it back. Sometimes it seems that clicking on places that a click doesn't ordinarily do anything will help.

Using 60.6.1esr (64-bit) on Debian 10 as installed through APT.

I see it regularly on the SUMO web site, along with some weird highlighting where the mouse button looks like it is stuck and the scroll as you hightlight text to copy does not scroll.

Using Firefox nightly and Thunderbird. The aberration also manifests in that user interface.

I am able to reproduce this on Discourse based forums in Firefox ESR (60.7.1esr 64-bit), including the official Discourse support forum when I reply to any discussion or edit a post.

The workaround David mentioned above (minimise and restore Firefox) does indeed cause the cursor to appear.

I am not able to reproduce this issue on the latest consumer Firefox 67.x or 68.x beta release, at least not with Discourse based forums.

This problem exists in the latest Thunderbird and has existed in Thunderbird for years. I thought that there was a separate bug report for that - for the problem in Thunderbird - but I cannot locate it (even using Bugzilla's 'advanced search'). I have though noticed a mozillaZine report (http://forums.mozillazine.org/viewtopic.php?f=39&t=584277) of the Thunderbird problem.

I find it hard to reproduce the problem. But using bullets, or indentation, might be a cause.

Given how hard the lack of a caret makes writing - and, especially, editing - an e-mail, this is a serious problem.

(In reply to Jo from comment #82)

(In reply to j.j. from comment #81)

Created attachment 9039166 [details]
simple testcase

I have a testcase attached here, can anyone reproduce the bug with that?

(I can't with any scaling factor)

Yes, cursor disappears in textarea between characters "x" and "t" and in [contenteditable] after typing "divvvvv"

I can reproduce this with Firefox 79.0 on Kubuntu 20.04. I've also had it happen on textareas without scaling factor. It's inconsistent though; I can't always reproduce it, but it definitely happens. I've also had it happen with Thunderbird on the same system. But I have never had it happen with the same version of Thunderbird on Debian 10 with MATE. I think it might be somehow tied to OS factors, such as fonts or rendering.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0

Hmm, can confirm using attachment 9039166 [details] (0.77 default scaling)

  • no blinking caret between "r" and "e" and between "e" and "a"
  • no caret after typing "divv"
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 18 votes.
:tnikkel, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(tnikkel)

All wysiwyg editors with internal css zoom function are not reasonably usable with firefox due to this bug

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(tnikkel)

(In reply to Jo from comment #93)

All wysiwyg editors with internal css zoom function are not reasonably usable with firefox due to this bug

Can you give specific steps to reproduce?

Flags: needinfo?(voss)

Can you give specific steps to reproduce?

see comment 91?
e.g if I type some "v"s after "div" the caret disapears at some points reproduceable

Summary: Cursor disappears sporadically → text cursor disappears sporadically with css scale down

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(voss)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: