Closed Bug 387534 Opened 13 years ago Closed 13 years ago

Caret not visible in Iframe with designMode="on"

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 391429

People

(Reporter: daniel, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(3 files)

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
Could you attach a testcase or give a page url that shows the problem?
Component: XULRunner → Editor
Product: Toolkit → Core
QA Contact: xulrunner → editor
Version: unspecified → Trunk
Attached file XUL testcase
A simple editor to show the problem
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)
Keywords: testcase
Thanks but that's a duplicate.
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 387380
(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.)
Yes, I think so too.
However, it should not prevent you from testing this again as soon as bug 387380 is fixed.
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
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Also reproducable with latest trunk: Mozilla/5.0 (Macintosh; U; PPC Mac OS
X Mach-O; de-DE; rv:1.9a8pre) Gecko/2007083108
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.
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.
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.
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?
Marco, that is probably something different, since in this bug, the caret doesn't show up at all.
OS: Windows XP → All
(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.
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.
(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....
Status: NEW → RESOLVED
Closed: 13 years ago13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 391429
You need to log in before you can comment on or make changes to this bug.