Closed Bug 259439 Opened 20 years ago Closed 19 years ago

XHTML Doctypes cause textarea input problem (control-right arrow) [selection]

Categories

(Core :: DOM: Editor, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: christopher.vance, Assigned: mozeditor)

References

()

Details

(Keywords: testcase)

Attachments

(2 files)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040914 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040914 Using a Doctype of either: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> OR <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd"> leads to problems working with text entered as described by the steps below. Reproducible: Always Steps to Reproduce: 1. Type a space. 2. Click to the right of the space (cursor should move to the right a bit). 3. Type at least two more words (to show what happens). 4. Place cursor at the beginning of the text in the textbox. 5. Hit Ctrl-Right arrow a few times to move the cursor word by word. Actual Results: Ctrl-Right will not place the cursor at the beginning of the first word typed after clicking at the end of the text. Expected Results: Ctrl-Right SHOULD place the cursor at the beginning of the first word typed after clicking at the end of the text. Occurs on Windows XP SP2: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040914 Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040914 Firefox/0.10 Occurs on Mandrake 9.2 (2.2 kernel): Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8 You can make the bug occur at multiple spots in the textbox by completing steps 1 through 3 multiple times (text added at the cursor position where you did the space+click). You can also add the text at these special position later: write some text, add space, click, add space, add text (so there are two spaces between the first set of words), and then go back to that special position and add text. That word in that spot will then be skipped when using Ctrl+Right arrow. I think there's something going on behind the scenes that is manifesting itself in this strange way.
Attached file XHTML 1.1 Testcase
Problem also occurs with the XHTML 1.1 Doctype.
Keywords: testcase
Sounds like the standards-mode handling of <br> is screwing something up?
Assignee: nobody → mozeditor
Component: Layout: Form Controls → Editor: Core
QA Contact: core.layout.form-controls → bugzilla
I'm using Mozilla 1.7.3 at the moment (Mac OSX). I can't reproduce this problem but perhaps I don't understand the steps; can someone clarify? For step 2, it says the cursor should move to the right after clicking to the right of the space. I don't see this behavior (I have in the past but not with either test case attached). How many pixels to the right (approximately) are you clicking? 5? 50? For step 4, how did you place the cursor (caret / insertion point) at the beginning of the text? Keyboard shortcut (if so, which ones)? Clicking? I don't understand "actual results." When did I click at the end of the text? Is that supposed to be "beginning?" Does the problem only result with a leading space or can you reproduce with a different character followed by a space? Is it possible to get a dump from the DOM on the textarea? Is this a recent regression? Did it ever work in a previous version of mozilla/firefox? Is it possible to reproduce it in a regular HTML file (is XHTML doctype required)? (btw, since this was re-assigned to the editor, my policy is to resolve bugs such as this as "WORKSFORME" if none of the questions above are answered within 4 weeks. Please respond at your earliest convenience.)
OK, I think I've reproduced it in Firefox PR1.0 on MacOSX. Unless I knew what was going on in the DOM (that the editor was doing something wrong), I'd guess that this is really a selection bug (moving the insertion point is part of selection). I'll leave it as an editor bug for now but I'd really like some of the answers to the above questions to know if this bug was in the right component or not. Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: XHTML Doctypes cause textarea input problem → XHTML Doctypes cause textarea input problem (control-right arrow) [selection]
(In reply to comment #4) > I'm using Mozilla 1.7.3 at the moment (Mac OSX). > I can't reproduce this problem but perhaps I don't understand the steps; can > someone clarify? I'll attempt to. > For step 2, it says the cursor should move to the right after clicking to the > right of the space. I don't see this behavior (I have in the past but not with > either test case attached). How many pixels to the right (approximately) are > you clicking? 5? 50? I have reproduced the problem by clicking roughly 5 pixels to the right of the cursor, as well as clicking 50 or 100 pixels away. I have also reproduced the bug by clicking to the bottom right of the cursor. Clicking to the bottom left, the cursor will move to a position in the text directly above the mouse pointer and will not produce the bug. > For step 4, how did you place the cursor (caret / insertion point) at the > beginning of the text? Keyboard shortcut (if so, which ones)? Clicking? I reproduced the bug by placing the cursor at the beginning of the textbox in the following separate ways: 1. Pressing the Home button to move the cursor. 2. Left-arrowing by way over until the cursor reachs the beginning. 3. Clicking the mouse at the beginning of the textbox. > I don't understand "actual results." When did I click at the end of the text? > Is that supposed to be "beginning?" I believe I changed my wording around before finally posting this bug. If you are typing something, hit the spacebar, and then happen to click at the end of the line, the next word typed AT THIS SPACE is skipped over when using Ctrl+Right to move between words. You can actually type stuff, go into the middle of the text, hit [SPACE], [ENTER], click to the right of the space to produce the bug, move the cursor to type somewhere else, and go back to that spot to type a word, and that word will be skipped when using Ctrl+Right. > Does the problem only result with a leading space or can you reproduce with a > different character followed by a space? To the best of my knowledge, this only occurs when the cursor caret is immediately after a space. Maybe I misunderstand the "leading space" reference, but this bug can occur in the middle of text, and not just at the beginning of the textbox. But yes, a space must preceed the caret for the mouse click to produce this problem. > Is it possible to get a dump from the DOM on the textarea? I don't know how this is done (with the DOM Inspector I assume). Please provide pointers here or via private email. > Is this a recent regression? Did it ever work in a previous version of > mozilla/firefox? As I wrote in my initial posting, the bug can be reproduced with FF 0.8. I will have to find an older release and test on that. > Is it possible to reproduce it in a regular HTML file (is XHTML doctype required)? The XHTML 1.0 strict or 1.1 doctype is indeed required. I could not dupe this with other doctypes (like XHTML 1.0 transistional or frameset, or HTML doctypes) or with not doctype present. > (btw, since this was re-assigned to the editor, my policy is to resolve bugs > such as this as "WORKSFORME" if none of the questions above are answered within > 4 weeks. Please respond at your earliest convenience.) This might be a text selection bug as suggested.
I can no longer reproduce this bug. I am fairly positive I saw it in Firefox 1.0. I just uninstalled 1.0 and installed the 1/18/05 nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050118 Firefox/1.0+). With this nightly I do not see the bug as I initially described. Selection works like it should. I assume this was fixed by a fix for something else? Close as WFM?
(In reply to comment #8) > I can no longer reproduce this bug. I am fairly positive I saw it in Firefox > 1.0. I just uninstalled 1.0 and installed the 1/18/05 nightly (Mozilla/5.0 > (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050118 Firefox/1.0+). Have all recent FF builds been using the same Mozilla codebase, or could a fix in the 1.8 beta branch have fixed this buggy behavior described here? My build of Seamonkey, rv:1.8b2, Gecko/20050224 does not exhibit this buggy behavior, and the 20050118 FF build referenced in comment #8, above, seems to use Seamonkey 1.8b and does not exhibit the bug. I see this bug again on both the attached testcases with the official FF 1.0.1 Windows release. HOWEVER, when clicking at the end of the space (in the initial bug report, this is step 2), the cursor no longer moves like did originally. Seen in Windows XP on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1. I hope I'm not making this more confusing. So: Could a fix have been checked into the Seamonkey 1.8 branch which fixes this textarea selection problem?
(In reply to comment #9) > So: Could a fix have been checked into the Seamonkey 1.8 branch which fixes this > textarea selection problem? Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2 Seeing in FF 1.0.2 RC for Windows. Last comment for tonight on this. I do not know what I can do from my end to fix this bug. Can someone else confirm, preferably in 1.0.2 RC or a newer nightly, that they can duplicate the buggy behavior?
> Have all recent FF builds been using the same Mozilla codebase No. > could a fix in the 1.8 beta branch have fixed this buggy behavior described > here? Definitely. > I see this bug again on both the attached testcases with the official FF 1.0.1 > Windows release. That's using a 1.7.x version of Gecko (read "a year old"). > Seeing in FF 1.0.2 RC for Windows. Again, that's using a 1.7.x Gecko. So are you seeing the problem in any nighlty build based on a current 1.8 Gecko?
WFM WinXP SP 2 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050907 (No IDN) Firefox/1.4 Deer Park Beta 1 seems to have the fix. Closing as WFM as the correct behavior will eventually make its way to the public through FF 1.5.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: