Bug 11746 – REGRESSION(r14931): Outlook Web Access incorrectly positions the insertion point when replying to e-mail

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Benjamin Olswang]

When using outlook web access to send an email the scroll bar to the right of the email body editing text box does not function.  This includes clicking on the scroll arrows, dragging the scroll bar, or using the mouse wheel.  So only using the up down arrows from the keyboard can be used. 

This is pretty tedious as when you make an new email with OWA, it starts the cursor at the bottom and scrolled to the bottom so you need to scroll all the way to the top.  Actually, this might be another bug as Firefox 2 starts a new email with the cursor at the bottom but scrolled to the tob so you can click at the top and start typing.

This is wth Outlook Web Access using Microsoft Exchange Server 2003 and I've reproduced with the version in 10.4.8 and the latest nightly.

I know this will be hard to reproduce unless you have access to some Outlook Web Access system.

[Alexey Proskuryakov]

I can reproduce both issues when using a nightly build, but shipping 10.4.8 Safari works correctly for me.

The problem with using scroll bars in nightlies is a known bug.

[Benjamin Olswang]

You're right.  It is working in 10.4.8 build.  My mistake.
And I didn't realize this was a general bug with scroll bars.  Sorry for the duplicate.

[Alexey Proskuryakov]

Confirming as a regression; renaming to reflect just the second issue. With shipping Safari, the insertion point is positioned at the top, and the text is not scrolled, which seems to be the correct behavior.

[David Kilzer (:ddkilzer)]

I've noticed this as well on OWA for Microsoft Exchange Server 2003.

I don't suppose any has tried to spoof a recent WebKit nightly as MSIE 6 on OWA For Exchange Server 2003 to see how broken the "Premium" client is, have they?

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> I've noticed this as well on OWA for Microsoft Exchange Server 2003.

Using the WebKit nightlies and some deduction, I've narrowed this down between:

r14926: works
r14941: fails

Since r14938 enabled the native text area implementation (see Bug8948), I'm pretty sure that this is the cause.  This bug still needs a reduction to figure out why the cursor isn't being positioned correctly when replying, though.

> I don't suppose any has tried to spoof a recent WebKit nightly as MSIE 6 on OWA
> For Exchange Server 2003 to see how broken the "Premium" client is, have they?

I tried this for fun, and it's not pretty.  Lots of JavaScript errors in the JS Console (beginning on the login page) and what looks like some kind of an XSLT issue.

[David Kilzer (:ddkilzer)]

Created attachment 11733 [details]
Reduced test case

[David Kilzer (:ddkilzer)]

(In reply to comment #6)
> Created an attachment (id=11733) [edit]
> Reduced test case

Basically, when the native textarea is focused, it puts the cursor at the end of the content instead of at the beginning.  The previous textarea implementation always put the cursor at the beginning of the content in the textarea.

[David Kilzer (:ddkilzer)]

(In reply to comment #5)
> Using the WebKit nightlies and some deduction, I've narrowed this down between:
> 
> r14926: works
> r14941: fails
> 
> Since r14938 enabled the native text area implementation (see Bug8948), I'm
> pretty sure that this is the cause.  This bug still needs a reduction to figure
> out why the cursor isn't being positioned correctly when replying, though.

Check that.  Revision r14935 enabled the native text area implementation, while r14936-r14938 fixed layout test results.

[David Kilzer (:ddkilzer)]

It appears that this change was made on purpose in r14931.  See comment in HTMLTextAreaElement::updateFocusAppearance() in WebCore/html/HTMLTextAreaElement.cpp.

    if (cachedSelStart == -1) {
        ASSERT(cachedSelEnd == -1);
        // If this is the first focus, set a caret at the end of the text.  
        // This matches other browsers' behavior.
        int max = static_cast<RenderTextControl*>(renderer())->text().length();
        setSelectionRange(max, max);
    } else

I haven't tested this on MSIE 6, but both Firefox 1.5.0.8 and Mozilla Suite 1.7.13 on Mac OS X do place the caret at the end of the text content.  The difference, though, is that they do not automatically scroll to the end of the content when this is done, so it's possible to click at the top of the text area without having to scroll all the way up. If, however, you start typing after the page loads, the text area will immediately scroll to the bottom as expected.

In summary, to match other browsers, Safari should place the caret at the end of the content, but not automatically scroll to the end.  Does that make sense?

[David Kilzer (:ddkilzer)]

Created attachment 11736 [details]
Patch v1 (fixes behavior; fails a few layout tests)

This patch fixes the behavior of OWA to match Firefox and Mozilla Suite, but a few layout tests fail now (due to the specific change in behavior).

Someone needs to decide if this is the desired behavior, then fix the layout tests appropriately.  (I may not have time to work on this myself, so feel free to take the patch and run with it.)

[David Kilzer (:ddkilzer)]

(In reply to comment #10)
> Created an attachment (id=11736) [edit]
> Fixes behavior; fails a few layout tests
> 
> This patch fixes the behavior of OWA to match Firefox and Mozilla Suite, but a
> few layout tests fail now (due to the specific change in behavior).

These are the layout tests that fail:

fast/forms/textarea-no-scroll-on-blur.html
fast/forms/textarea-scrolled-endline-caret.html
fast/forms/textarea-scrolled-type.html

[Alexey Proskuryakov]

I tried the attached test in MSVC 6, and the insertion point is positioned at the top. The Firefox behavior that we now emulate doesn't look right to me.

[David Kilzer (:ddkilzer)]

Adele, do you recall which browser(s) you were emulating when you changed the native textarea to put the caret at the end of the content instead of the beginning (in r14931)?

[Adele Peterson]

I was trying to emulate Firefox, but perhaps FF has a more complex rule than this. Or maybe their behavior has changed.

[David Kilzer (:ddkilzer)]

Modern browser behavior
-----------------------

Firefox 1.5.0.8/2.0:

Initial focus:
- Caret placed at end of content
- Text area drawn with beginning of content
- Typing immediately scrolls to end of content where text is inserted

Subsequent focus using tab/shift-tab:
- Same as initial focus
- Previous caret position is remembered

Subsequent focus using mouse to click on scrollbar:
- Same as initial focus
- Previous caret position is remembered


MSIE 5.2.3 for Mac (not modern, but I was curious!):

Initial focus (like Firefox):
- Caret placed at end of content
- Text area drawn with beginning of content
- Typing immediately scrolls to end of content where text is inserted

Subsequent focus using tab/shift-tab (like Safari):
- Entire content is selected after hitting tab, then shift-tab
- Text area drawn with beginning of content with scrolling if needed
- Typing replaces entire content
- Previous caret position obliterated with select-all behavior

Subsequent focus using mouse to click on scrollbar (almost like MSIE 6.0):
- Caret placed at beginning of content (no scrolling)
- Text area drawn with previous content visible (no scrolling)
- Typing inserts at beginning of content with scrolling if needed
- No memory of previous caret position (always places at beginning of content)


MSIE 6.0:

Initial focus:
- Caret placed at beginning of content
- Text area drawn with beginning of content
- Typing inserts at beginning of content (no scrolling)

Subsequent focus using tab/shift-tab:
- Caret placed at end of content
- Text area drawn with end of content
- Typing inserts at end of content
- No memory of previous caret position (always places at end of content)

Subsequent focus using mouse to click on scrollbar:
- Caret placed at beginning of content
- Text area drawn with beginning of content
- Typing inserts at beginning of content (no scrolling)
- No memory of previous caret position (always places at beginning of content)


Mozilla Suite 1.7.13:

- Same as Firefox 1.5.0.8/2.0


OmniWeb 5.5.1:

- Same as Safari 2.0.4
- Form Editor feature always places caret at end of Form Editor window


Opera 9.0.2:

Initial focus:
- Caret placed at beginning of content
- Text area drawn with beginning of content
- Typing inserts at beginning of content (no scrolling)

Subsequent focus using tab/shift-tab:
- N/A: Opera doesn't provide tab/shift-tab navigation

Subsequent focus using mouse to click on scrollbar:
- Same as initial focus
- Previous caret position is remembered


Safari 2.0.4:

Initial focus:
- Caret placed at beginning of content
- Text area drawn with beginning of content
- Typing inserts at beginning of content (no scrolling)

Subsequent focus using tab/shift-tab:
- Entire content is selected after hitting tab, then shift-tab
- Text area drawn with beginning of content
- Typing replaces entire content
- Previous caret position obliterated with select-all behavior

Subsequent focus using mouse to click on scrollbar:
- Same as initial focus
- Previous caret position is remembered

[David Kilzer (:ddkilzer)]

Based on Comment #15, I'd like to see the following with WebKit (which is basically Opera 9.0.2 with keyboard navigation mimicking mouse clicking).  Thoughts?

Initial focus:
- Caret placed at beginning of content
- Text area drawn with beginning of content
- Typing inserts at beginning of content (no scrolling)

Subsequent focus using tab/shift-tab:
- Same as initial focus
- Previous caret position is remembered

Subsequent focus using mouse to click on scrollbar:
- Same as initial focus
- Previous caret position is remembered

Note that Bug 11767 was filed since clicking on the scrollbar in the next text areas does not "fully" focus it (no caret and no typing is possible), unlike using tab/shift-tab.

[David Kilzer (:ddkilzer)]

Created attachment 11750 [details]
Patch v2 (needs changelog and layout test fixes)

This patch implements the behavior described in Comment #16.

Still needs a changelog entry and layout test fixes (and a new layout test if existing tests don't cover it).

[David Kilzer (:ddkilzer)]

Created attachment 11790 [details]
Patch v3

Implements behavior described in Comment #16.  Includes layout test updates, a new layout test for this bug, and changelog entries.

[Darin Adler]

I know it's just my opinion, but I think caret at end of content is way better.

[Darin Adler]

Comment on attachment 11790 [details]
Patch v3

This approach to sending the caret to the bottom of the text area:

+            eventSender.keyDown(String.fromCharCode(0xf701), ["metaKey"]);


is entirely Macintosh-specific. I think it would be better to not rely on that and the eventSender for tests that would otherwise be more portable.

I think that ta.setSelectionRange(10000, 10000) will do the job just as well without being platform-specific.

I think the comment should include the URL <http://bugs.webkit.org/show_bug.cgi?id=11746#c16>.

[David Kilzer (:ddkilzer)]

(In reply to comment #19)
> I know it's just my opinion, but I think caret at end of content is way better.

I've found the opposite to be true, but most of the time this behavior comes into play is when I'm replying to messages via web mail--either OWA or Yahoo! Mail.  Since making the change in my local build, though, I have yet to run into a case where I wished the cursor was at the end rather than the beginning of the content (but it's only been a week).

Hixie, do you have any input on this for HTML 5?  I didn't see anything related to initial caret position in the current spec (search for "textarea" to find more info):

http://www.whatwg.org/specs/web-apps/current-work/#the-textarea

[Ian 'Hixie' Hickson]

Browsers should just do whatever the platform convention is.

[Darin Adler]

(In reply to comment #22)
> Browsers should just do whatever the platform convention is.

I don't agree.

First of all, platforms don't have clear conventions for this.

Second, this bug shows that this won't work for compatibility. Sites make assumptions based on the browser they first test on, and using the Macintosh platform convention prevents this site from working correctly.

[David Kilzer (:ddkilzer)]

(In reply to comment #20)
> (From update of attachment 11790 [details] [edit])
> This approach to sending the caret to the bottom of the text area:
> 
> +            eventSender.keyDown(String.fromCharCode(0xf701), ["metaKey"]);
> 
> is entirely Macintosh-specific. I think it would be better to not rely on that
> and the eventSender for tests that would otherwise be more portable.
> 
> I think that ta.setSelectionRange(10000, 10000) will do the job just as well
> without being platform-specific.

This doesn't work.  The textarea is not redrawn after the selection changes.  I'm still trying to figure out how to use ta.setSelectionRange().  (I'd also prefer to use ta.value.length instead of an arbitrary value of 10000, which should work just as well.)

[David Kilzer (:ddkilzer)]

(In reply to comment #24)
> This doesn't work.  The textarea is not redrawn after the selection changes. 
> I'm still trying to figure out how to use ta.setSelectionRange().  (I'd also
> prefer to use ta.value.length instead of an arbitrary value of 10000, which
> should work just as well.)

Replacing this:

    eventSender.keyDown(String.fromCharCode(0xf701), ["metaKey"]);

With setSelectionRange() requires an extra set of focus()/blur() calls to work:

    ta.focus();
    ta.setSelectionRange(ta.value.length, ta.value.length);
    ta.blur();

New patch in a few.

[David Kilzer (:ddkilzer)]

Created attachment 11897 [details]
Patch v4

Changes from Patch v3 per Comment #20:

- Uses ta.setSelectionRange() (with extra focus()/blur() calls) instead of window.eventSender().
- Adds URL to comment in HTMLTextAreaElement.cpp.

[Darin Adler]

Comment on attachment 11897 [details]
Patch v4

r=me

[David Kilzer (:ddkilzer)]

Committed revision 18341.