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)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: christopher.vance, Assigned: mozeditor)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(2 files)

XHTML 1.0 Strict testcase
171 bytes, text/html
Details
XHTML 1.1 Testcase
159 bytes, text/html
Details 
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: