Summary: | REGRESSION(r14931): Outlook Web Access incorrectly positions the insertion point when replying to e-mail | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Benjamin Olswang <bolswang> | ||||||||||||
Component: | HTML Editing | Assignee: | David Kilzer (:ddkilzer) <ddkilzer> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Minor | CC: | adele, ap, darin, ddkilzer, ian | ||||||||||||
Priority: | P1 | Keywords: | HasReduction, Regression | ||||||||||||
Version: | 420+ | ||||||||||||||
Hardware: | Mac (Intel) | ||||||||||||||
OS: | OS X 10.4 | ||||||||||||||
Attachments: |
|
Description
Benjamin Olswang
2006-12-03 10:44:16 PST
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. 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. 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. 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? (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. Created attachment 11733 [details]
Reduced test case
(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. (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. 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? 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.)
(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 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. 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)? I was trying to emulate Firefox, but perhaps FF has a more complex rule than this. Or maybe their behavior has changed. 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 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. 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). 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. I know it's just my opinion, but I think caret at end of content is way better. 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>. (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 Browsers should just do whatever the platform convention is. (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. (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.) (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. 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. Comment on attachment 11897 [details]
Patch v4
r=me
Committed revision 18341. |