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

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=11746


ddkilzer at kilzer.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at hixie.ch




------- Comment #15 from ddkilzer at kilzer.net  2006-12-06 04:27 PDT -------
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


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.