Closed Bug 395965 Opened 17 years ago Closed 15 years ago

Caret drawn vertically offset in designMode IFrame

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 308736

People

(Reporter: cpearce, Unassigned)

References

Details

(Keywords: testcase)

Attachments

(1 file)

Test case
2.05 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091215 Minefield/3.0a8pre WITH PATCH 280069

I first reported this issue as a comment in Bug 335856... When you apply Peter Van der Beken's patch 280069 for Bug 335856, another (unrelated) issue shows up; under certain conditions, when an iframe in designMode first gets focus, its caret is drawn half way up the first line, with the top clipped.

Steps to reproduce:

1. Create an iframe with no src attribute set.
2. Enable designMode for that iframe.
3. Write the a blank HTML document into the iframe after enabling designMode, e.g.:
    var editdoc = document.getElementById('iframeId').contentDocument;
    editdoc.designMode = 'on';
    editdoc.open('text/html', 'replace');
    editdoc.write('<html><head></head><body></body></html>');
    editdoc.close();
4. Click on the iframe to gain focus.
5. Notice that the caret is drawn half way up the first line.

You will notice that the bottom of the caret lies half way up the first line, rather than with its bottom at the bottom of the line. If you enter text, the caret correctly appears where it should vertically, even after you delete the text you've entered. However, if you turn on designMode *after* you've written the text into the iframe, you'll notice that the caret is aligned correctly. 

What's happening, is that a <br> is being inserted when design mode is being turned on. So when we write a blank HTML document into the iframe *after* we've turned on designMode, no <br> has been added when we turned on designMode. Then when we come to extract the nsIFrame to draw the nsCaret into (by calling nsFrameSelection::GetFrameForNodeOffset() in nsCaret::GetCaretFrameForNodeOffset()), we extract an nsIFrame which has zero height. Later when we pass that nsIFrame to  nsCaret::UpdateCaretRects(), UpdateCaretRects() sees that it's a zero-height nsIFrame, which results in it offsetting the mCaretRect by the font ascent. This results in mCaretRect having a negative y coord, and means the caret is drawn such that it finished half way up the line.

Test case to be attached...

So, how can we fix this, and should we? Should we more aggresively add <br>? I note that this bug does affect the Xbox forums, and could affect other sites, though it's not hard for them to fix their sites to display the caret correctly.

Reproducible: Always

Steps to Reproduce:

1. Create an iframe with no src attribute set.
2. Enable designMode for that iframe.
3. Write the a blank HTML document into the iframe after enabling designMode, e.g.:
    var editdoc = document.getElementById('iframeId').contentDocument;
    editdoc.designMode = 'on';
    editdoc.open('text/html', 'replace');
    editdoc.write('<html><head></head><body></body></html>');
    editdoc.close();
4. Click on the iframe to gain focus.


Actual Results:  
The caret is drawn with its bottom ending half way up the first line.

Expected Results:  
The bottom of the caret should be at the bottom of the first line.
(In reply to comment #1)
> Created an attachment (id=280660) [details]
> Test case
> 

Note the test case requires Patch 280069 to be applied for it to show up.
Adding Peter to CC list. Peter, can you please comment on what we should do about this bug?
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
(In reply to comment #2)
> Note the test case requires Patch 280069 to be applied for it to show up.

As a note, that's the patch from bug 335856.

It's a bit confusing to file bugs for patches that haven't landed yet, but I guess it's all right.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: testcase
Blocks: 424615
This seems related/the same as bug 308736.
Depends on: 308736
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: