387534 - Caret not visible in Iframe with designMode="on"

Status: RESOLVED DUPLICATE of bug 391429

(Core :: DOM: Editor, defect)

Description

[Daniel Kirsch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.4) Gecko/20070515 Firefox/2.0.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a7pre) Gecko/2007070909

With the latest nightly the blinking caret is not visible in an editable iframe element (using the designMode="on" property) anymore.
(Writing and selecting text works.)

Reproducible: Always

Comment 1

[Martijn Wargers (dead)]

Could you attach a testcase or give a page url that shows the problem?

Comment 2

[Daniel Kirsch]

Attachment: XUL testcase

A simple editor to show the problem

Comment 3

[Daniel Kirsch]

Attachment: html document for the editor testcase

Comment 4

[Daniel Kirsch]

Attachment: Complete Testcase for XULRunner

The zip contains all necessary files to run the midas test in a chrome environment. Add the current extracted XULRunner nightly into the xulrunner subfolder and run the app using start.bat (windows)

Comment 5

[Caio Tiago Oliveira (asrail)]

Thanks but that's a duplicate.

Comment 6

[Daniel Kirsch]

(In reply to comment #5)
> Thanks but that's a duplicate.

OK. (If "caret browsing" and editing a document using designMode="on" uses the same caret implementation/bugs.)

Comment 7

[Martijn Wargers (dead)]

Yes, I think so too.
However, it should not prevent you from testing this again as soon as bug 387380 is fixed.

Comment 8

[Daniel Kirsch]

While bug 387380 is marked as fixed I can still reproduce the missing caret in an Iframe with designMode="on" with the latest XULRunner nightly 
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.9a8pre) Gecko/2007082709

Comment 9

[Martijn Wargers (dead)]

Yeah, I can reproduce this with a 2007-08-27 trunk xulrunner build. I can edit the text just fine, but there is no caret showing up.
It is worksforme with Firefox trunk.

Is this a packaging problem or something, maybe?
Also, I noticed that links and absolute positioned divs don't get the necessary styling, which they normally would get from designmode.css and contenteditable.css.

Comment 10

[Georg Maaß]

Also reproducable with latest trunk: Mozilla/5.0 (Macintosh; U; PPC Mac OS
X Mach-O; de-DE; rv:1.9a8pre) Gecko/2007083108

Comment 11

[Georg Maaß]

How can I change Hardware and OS to ALL, because it is not restricted to PC and Windows; it also ocures on Mac with MacOS X 10.4.

Comment 12

[Georg Maaß]

The crasher of https://bugzilla.mozilla.org/show_bug.cgi?id=391819 prevented us from testing this fix. Now we changed the iframe.type to "content" we still have no caret, and even if we remove the attribute, we do not get a caret.

Comment 13

[Georg Maaß]

Using Minefield Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US;
rv:1.9a8pre) Gecko/2007090104 Minefield/3.0a8pre instead of XulRunner also does not display the caret.

Comment 14

[Marco Zehe (:MarcoZ)]

Could this bug be responsible also for the following behaviour I'm seeing with Thunderbird 3.0 nightlies: When composing a message or replying to one, initially the caret is not visible. I have to physically click inside the composition window to get the caret to appear.

Is this related, or something completely different?

Comment 15

[Martijn Wargers (dead)]

Marco, that is probably something different, since in this bug, the caret doesn't show up at all.

Comment 16

[Marco Zehe (:MarcoZ)]

(In reply to comment #15)
> Marco, that is probably something different, since in this bug, the caret
> doesn't show up at all.

Agreed! The bug describing my behaviour is bug 386872, which I've been pointed to in the meantime.

Comment 17

[Georg Maaß]

With XulRunner Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; de-DE; rv:1.9a9pre) Gecko/2007092208 the problem is still present.

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #9)
> Is this a packaging problem or something, maybe?
> Also, I noticed that links and absolute positioned divs don't get the necessary
> styling, which they normally would get from designmode.css and
> contenteditable.css.

That's what I theorized in bug 391429 comment 2, but I don't know where to look for XR packaging manifests or whatever :(

Tinderbox log for the Mac XR is showing contenteditable.css and designmode.css getting shoved into dist/bin/res and then into XUL.framework, which throws a wrench in that theory, though....