Closed
Bug 395965
Opened 17 years ago
Closed 15 years ago
Caret drawn vertically offset in designMode IFrame
Categories
(Core :: DOM: Editor, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 308736
People
(Reporter: cpearce, Unassigned)
References
Details
(Keywords: testcase)
Attachments
(1 file)
|
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.
|
Reporter | |
Comment 1•17 years ago
|
||
|
|
Reporter | |
Comment 2•17 years ago
|
||
(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.
|
|
Reporter | |
Comment 3•17 years ago
|
||
Adding Peter to CC list. Peter, can you please comment on what we should do about this bug?
|
||
Updated•17 years ago
|
Component: General → Editor
Product: Firefox → Core
QA Contact: general → editor
|
||
Comment 4•17 years ago
|
||
(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.
|
|
||
Comment 5•17 years ago
|
||
This seems related/the same as bug 308736.
|
||
Updated•15 years ago
|
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.
Description
•