846943 - Caret is invisible when entering an empty designmode field - regression

Status: RESOLVED WORKSFORME

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

Description

[cthomson]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.2; WOW64; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MS-RTC LM 8; .NET4.0C)

Steps to reproduce:

I am encountering the same problem described in Bug 308736 (marked fixed in 2009)where if you have an iframe in designmode and the body element inside of the iframe has no children, I click inside of the iframe.

From the original bug posting:

http://www.kevinroth.com/rte/demo.htm
https://bugzilla.mozilla.org/attachment.cgi?id=381763



Actual results:

No caret appeared.


Expected results:

A blinking caret should appear inside of the iframe to provide feeback to the user (i.e. that it is ok to start typing).

Comment 1

[cthomson]

Correcting Product to be "Core" to match 381763.  Hopefully this is correct...

Comment 2

[cthomson]

I've gone back through Firefox versions from 19 version by version.  I can't reproduce the problem in Firefox 14 but can in 15.0.1 and later.

Comment 3

[Loic]

1) Test in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode) and with a fresh profile (don't import anything, see https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles)

2) If the issue is still reproducible with FF19 in both cases, use the tool mozregression to find a possible regression range, see http://harthur.github.com/mozregression/
(FF15 builds started in April, eg mozregression --good=2012-04-01)

Comment 4

[cthomson]

I've done a full "factory reset" of Firefox 19, deleting my existing profile, creating a new one, no plugins installed and can reproduce the problem using the test case attached to Bug 308736.

Ran through 'mozregression --good=2012-04-01', result was:

Last good nightly: 2012-05-04
First bad nightly: 2012-05-05

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2db9df42823d&tochange=0a48e6561534

Comment 5

[Loic]

Thanks for the regression, it helps. I'm able to see the bug too.
Testcase: https://bug308736.bugzilla.mozilla.org/attachment.cgi?id=381760

Comment 6

[cthomson]

Not a problem, happy to help out.  Thank you for confirming that it is reproducible outside of my environment.

I'm not sure if it worth noting that I am seeing the related bug 395965 (marked as duplicate of original bug 308736) too.  In that case I type some text which initially makes the caret appear properly, but if I then empty out the editor by deleting the text, sometimes the caret only remains partially visible due to it being shifted upwards off the top of the iframe resulting in it being cut off.  There must be some other factor at play though since it doesn't happen 100% of the time for me.

Comment 7

[Alice0775 White]

Regression window(m-i)
Good:
http://hg.mozilla.org/integration/mozilla-inbound/rev/7e237e96018f
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120503165348
Bad:
http://hg.mozilla.org/integration/mozilla-inbound/rev/97d04250e23c
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120503171349
Pushlog:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7e237e96018f&tochange=97d04250e23c

In local build:
Last Good: 0cb419f67ab7
First Bad: 12cb1f643adb

Regressed by: 
  12cb1f643adb	Mats Palmgren — Bug 735641 - No way to deselect image of image document after select all (Ctrl+A). r=bz

Comment 8

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The test case has gone, and I cannot reproduce this with data:text/html,<script>addEventListener("load", () => document.designMode='on');</script>.