Closed Bug 335856 Opened 15 years ago Closed 14 years ago
Can't easily put caret in this designmode iframe testcase (caret doesn't show up)
Follow-up from bug 306267. See upcoming testcase. You see two iframes which are both in designMode. In both instances you should see a caret when clicking inside the iframe. This happens for the right iframe, but not for the left one. Testcase is comparable with the testcase in bug 306267, only I removed the bordered box inside the iframe.
Summary: Can't easily put caret in this designmode iframe testcase → Can't easily put caret in this designmode iframe testcase (caret doesn't show up)
This has become worse now that bug 237964 has landed. Now, the left iframe thinks it has a designMode document, but now it has become impossible to type anything in it.
Assignee: nobody → peterv
OS: Windows XP → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.9 M9
Peter's patch does allow text to be edited again. However there are two problems... 1. When you click in (or tab into) the left iframe of Martijn's test case, the cursor appears roughly half way up the first line, i.e. it's offset by half it's height upwards from where it should be. Once you enter text however, the cursor returns to normal. 2. You can't shift-tab to switch focus out of either iframe. Tab does switch focus to the next widget though. 3.
(In reply to comment #4) > 1. When you click in (or tab into) the left iframe of Martijn's test case, the > cursor appears roughly half way up the first line, i.e. it's offset by half > it's height upwards from where it should be. Once you enter text however, the > cursor returns to normal. I think this might be an issue that was already there. You might want to file a new bug on that as soon as Peter's patch has landed (if it hasn't been filed already). > 2. You can't shift-tab to switch focus out of either iframe. Tab does switch > focus to the next widget though. That's bug 390278.
I have added Bug 395965 to handle the bug shown up in #1 above, along with analysis of what causes it. Peter, could you please take a look and advise what we should do about it?
This make the editor deal with changes of the root element by removing/attaching the listeners when the root element is removed/inserted. It also sets the selection at the beginning of the document if there is no body element when focusing the editable document. I'm not really sure how I can write a testcase for this, setting the caret with a mouse click is possible but I don't know how to get the location of the caret.
Comment on attachment 283207 [details] [diff] [review] v1 r+sr=jst
Checked in (without blocking1.9+ but it fixes bug 393568 which does ahve blocking1.9+). I'll try to come up with a way to automate the testcase.
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: blocking1.9? → in-testsuite?
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.