Closed Bug 795785 Opened 7 years ago Closed 7 years ago

editor isn't scrolled to the caret position if editor specified overflow: hidden;

Categories

(Core :: Editor, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla18
Tracking Status
firefox15 --- wontfix
firefox16 --- wontfix
firefox17 + wontfix
firefox18 + verified
firefox-esr10 - wontfix
firefox-esr17 - wontfix

People

(Reporter: masayuki, Assigned: masayuki)

References

()

Details

(Whiteboard: [parity-IE][parity-Chrome][parity-Safari][parity-Opera])

Attachments

(5 files, 2 obsolete files)

8.63 KB, patch
Ehsan
: review+
smaug
: review+
Details | Diff | Splinter Review
17.64 KB, patch
Details | Diff | Splinter Review
6.11 KB, patch
Details | Diff | Splinter Review
3.97 KB, patch
smaug
: review+
Details | Diff | Splinter Review
4.03 KB, patch
smaug
: review+
Details | Diff | Splinter Review
reported via fxinput: http://input.mozilla.org/opinion/3236299

The editor of twitter is specified overflow: hidden;. Then, when we input longer text then the editor, the overflowed text is clipped. This happens a lot of times with Japanese language because the average character width is wider than Western languages and composition string is longer than its final result.

So, I think that editor should scroll to the caret position after something is inputted even if the overflow is hidden.

dbaron, do you have objection about the behavior for overflow: hidden;?
FYI: IE, Chrome, Safari and Opera scrolls to caret after editing the editor in twitter.
Attached patch Patch (obsolete) — Splinter Review
This patch just ensures that editor always do "selection into view" after editing. If users just move the caret, scroll doesn't occur. I'm looking the code about it, but I think that it should be done in another bug.
Attachment #666449 - Flags: superreview?(bugs)
Attachment #666449 - Flags: review?(ehsan)
Attachment #666449 - Flags: review?(bugs)
Attachment #666449 - Flags: feedback?(dbaron)
What feedback did you want from me?
Comment on attachment 666449 [details] [diff] [review]
Patch

Review of attachment 666449 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, but if we do this, we also need to scroll when moving the caret using the keyboard.

Also, what happens if the user tries to scroll by making a selection and try to extend it past the bounds of the editable area?
Attachment #666449 - Flags: review?(ehsan) → review+
(In reply to David Baron [:dbaron] from comment #3)
> What feedback did you want from me?

About the last line of comment #0.

IIRC, you said that scrollable elements which are specified overflow: hidden; shouldn't be scrollable by user input such as mouse wheel or keyboard. So, if you think that we shouldn't fix this bug with my approach, we need to contact twitter.com.

However, in all other browsers, we can scroll the editor content by either caret move or text input. Therefore, I don't think we should keep our behavior in editors.

So, I want to know your thought about this issue.

(In reply to Ehsan Akhgari [:ehsan] from comment #4)
> r=me, but if we do this, we also need to scroll when moving the caret using
> the keyboard.

Thank you for your review. Yeah, I think so. But I'm not sure whether we should scroll overflow: hidden; contents in the caret browsing mode too. Therefore, I'd like to discuss about this issue in another bug.

> Also, what happens if the user tries to scroll by making a selection and try
> to extend it past the bounds of the editable area?

Nothing changed by this patch. The expanding selection by keyboard doesn't cause scroll in such editor. However, when I press up key at first line or down key at last line, it causes scrolling. I'm not sure the reason.
(In reply to comment #5)
> (In reply to David Baron [:dbaron] from comment #3)
> > What feedback did you want from me?
> 
> About the last line of comment #0.
> 
> IIRC, you said that scrollable elements which are specified overflow: hidden;
> shouldn't be scrollable by user input such as mouse wheel or keyboard. So, if
> you think that we shouldn't fix this bug with my approach, we need to contact
> twitter.com.
> 
> However, in all other browsers, we can scroll the editor content by either
> caret move or text input. Therefore, I don't think we should keep our behavior
> in editors.
> 
> So, I want to know your thought about this issue.
> 
> (In reply to Ehsan Akhgari [:ehsan] from comment #4)
> > r=me, but if we do this, we also need to scroll when moving the caret using
> > the keyboard.
> 
> Thank you for your review. Yeah, I think so. But I'm not sure whether we should
> scroll overflow: hidden; contents in the caret browsing mode too. Therefore,
> I'd like to discuss about this issue in another bug.
> 
> > Also, what happens if the user tries to scroll by making a selection and try
> > to extend it past the bounds of the editable area?
> 
> Nothing changed by this patch. The expanding selection by keyboard doesn't
> cause scroll in such editor. However, when I press up key at first line or down
> key at last line, it causes scrolling. I'm not sure the reason.

That sucks, please file a follow-up to investigate this.  Thanks!
So what happens if you type something to a overflow:hidden editor so that the content is scrolled.
Then you move cursor to the start of the text (so that the overflown are is hidden).
How can you see the end of the text you just typed?
(In reply to Olli Pettay [:smaug] from comment #7)
> So what happens if you type something to a overflow:hidden editor so that
> the content is scrolled.

Editor is not scrolled with current build. The patch makes editor scrolled to the end of inserted text because the caret is always moved to there.

> Then you move cursor to the start of the text (so that the overflown are is
> hidden).

Nothing happens even with the patch. I need more work for it in another bug. See the end of comment 5 for the detail.

> How can you see the end of the text you just typed?

The patch makes it shown into the view automatically. I think that this patch helps twitter users in most cases.
But does this really help? After you have stopped typing, you can't actually see the whole
text.
(In reply to Olli Pettay [:smaug] from comment #9)
> But does this really help? After you have stopped typing, you can't actually
> see the whole
> text.

Yes. For example, composition string of IME is usually longer than the final (committed) text. When I type Hiragana characters, it sometimes overflows from the editor of twitter.com. Then, I cannot see whether the *inputting* text is typed as expected until converting, committing and press down key. But I can confirm the inputting text with the patched build. I feel it really helps users to type Japanese text.
So, I mean that during IME composition, users never see the overflown composition text. There is no way to access it.
But after typing, can you scroll the text? If not, some of it is hidden and you can't check
what you actually typed.
I'm a bit worried that it is easier to type long text, but after typing it is not
possible to see it all.
(In reply to Olli Pettay [:smaug] from comment #12)
> But after typing, can you scroll the text? If not, some of it is hidden and
> you can't check
> what you actually typed.

It's true in some situations. However, I don't see such overflow: hidden; editor except twitter.com (in Facebook, the editor looks like overflow: hidden; but the editor will be expanded when I type long text). So, I want to help users in twitter actually. From this viewpoint, the editor can show 4 lines. The enough space doesn't cause what you worry about.
(In reply to comment #14)
> (In reply to Olli Pettay [:smaug] from comment #12)
> > But after typing, can you scroll the text? If not, some of it is hidden and
> > you can't check
> > what you actually typed.
> 
> It's true in some situations. However, I don't see such overflow: hidden;
> editor except twitter.com (in Facebook, the editor looks like overflow: hidden;
> but the editor will be expanded when I type long text). So, I want to help
> users in twitter actually. From this viewpoint, the editor can show 4 lines.
> The enough space doesn't cause what you worry about.

Well I agree that your patch improves things, but if we wanna do that then we should also fix scrolling in other cases, which pretty much amounts to ignoring overflow:hidden on text controls altogether.
The second patch makes editable editors scrollable by caret move. This might not be good enough, but I think that this temporarily improves the a11y.
smaug:

Now, the second patch makes caret move cause scrolling, would your review the both patches?

dbaron:

I'd like to confirm your idea. Do you have any objection for scrolling the overflow:hidden; editors even though current behavior actually causes a11y issue in twitter.com? So, I mean that should this be an evangelism bug?
This is not an our regression but twitter has changed the editor behavior. It used to resize the editor for long text, but now, the size is fixed. This is major problem in very famous website and other browsers don't have this problem. So, I think that we should take care as far as possible.
Whiteboard: [parity-IE][parity-Chrome][parity-Safari][parity-Opera]
Attachment #667800 - Flags: review?(bugs) → review+
Attachment #666449 - Flags: superreview?(bugs)
Attachment #666449 - Flags: superreview+
Attachment #666449 - Flags: review?(bugs)
Attachment #666449 - Flags: review+
This all is risky.

Would it be hard to limit the behavior to <input> and <textarea> and would that fix twitter case?
Also, how do other browsers handle contentEditable with overflow:hidden?
(In reply to Olli Pettay [:smaug] from comment #22)
> This all is risky.

Yeah, unfortunately.

> Would it be hard to limit the behavior to <input> and <textarea> and would
> that fix twitter case?

It's possible. The risk of part.1 isn't so changed. But the part.2 patch (this is risky) can be replaced with another patch which fixes this bug in nsEditorCommands.cpp.

> Also, how do other browsers handle contentEditable with overflow:hidden?

IE, Safari and Chrome work same as <textarea>. Caret move in Opera doesn't work fine, though.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #23)
> (In reply to Olli Pettay [:smaug] from comment #22)
> > Would it be hard to limit the behavior to <input> and <textarea> and would
> > that fix twitter case?
> 
> It's possible. The risk of part.1 isn't so changed. But the part.2 patch
> (this is risky) can be replaced with another patch which fixes this bug in
> nsEditorCommands.cpp.

So, I think that if we could fix this bug on Aurora, only changing part.2 is the safest way.
Isn't the next merge tomorrow. But perhaps if you land the patches early in your time, that is ok.
https://hg.mozilla.org/mozilla-central/rev/3d8d4f10eb62
https://hg.mozilla.org/mozilla-central/rev/0c48cbf5e4c5
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
What can't the user do when the caret position is incorrectly placed? Sorry, we're not fully understanding the impact here. Unclear if this is minor or critical.
(In reply to Alex Keybl [:akeybl] from comment #31)
> What can't the user do when the caret position is incorrectly placed?

If the caret is placed outside of the visible rectangular of the editor, user cannot confirm what he/she typed actually. See the video attached to Bug 797332.
https://bugzilla.mozilla.org/attachment.cgi?id=667455

This is more serious bug for CJK users. Chinese, Japanese and Korean characters are wider than Western alphabets. So, the editor of twitter.com cannot show 140 CJK characters without scroll (only about 70 CJK characters can be contained in the editor rectangular). Additionally, Japanese users need to use Japanese IME. Users input Kana characters which indicate pronunciation first, an then convert to Chines characters which indicate meaning of the words. So Japanese users cannot check the result of IME conversion if the text is overflown from the editor rectangular.

> Sorry,
> we're not fully understanding the impact here. Unclear if this is minor or
> critical.

Sorry for the not enough explanation. If we can fix this bug in other branches, we can lower risk patch for the part.2 patch. Unfortunately, a part of the changed code is shared with non-editor such as caret browsing mode. So, the part.2 patch is pretty risky for Aurora and Beta.

The alternative patch for part.2 affects only editors for <input> and <textarea>. So, not fixes same issue of HTML editor. However, it's enough for current purpose, i.e., for fixing the twitter.com issue.
Go ahead and nominate for uplift, tracking for Beta/Aurora.
Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)

Then, we should take this to beta (17).
Attachment #668913 - Flags: review?(bugs)
Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)


>-function doEnterKeyTest(aElement, aElementDescription, aCallback)
>+function doEnterKeyAndArrowKeyTest(aElement, aElementDescription, aDoTestCursorMove, aCallback)
> {
>   aElement.focus();
>   aElement.scrollTop = 0;
>   hitEventLoop(function () {
>     is(aElement.scrollTop, 0,
>        aElementDescription + "'s scrollTop isn't 0");
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     hitEventLoop(function () {
>       isnot(aElement.scrollTop, 0,
>             aElementDescription + " was not scrolled by inserting line breaks");
>-      aCallback();
>+      if (!aDoTestCursorMove) {
>+        aCallback();
>+        return;
>+      }
>+      var scrollTop = aElement.scrollTop;
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      hitEventLoop(function () {
>+        isnot(aElement.scrollTop, scrollTop,
>+              aElementDescription + " was not scrolled by up key events");
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        hitEventLoop(function () {
>+          is(aElement.scrollTop, scrollTop,
>+             aElementDescription + " was not scrolled by down key events");
>+          aCallback();
>+        }, 20);
>+      }, 20);
>     }, 20);
>   }, 20);
> }


Don't we need also VK_LEFT/RIGHT tests?
Attachment #668913 - Flags: review?(ehsan)
Attachment #668913 - Flags: review?(bugs)
Attachment #668913 - Flags: review+
Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)

Review of attachment 668913 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the added VK_LEFT/VK_RIGHT tests.
Attachment #668913 - Flags: review?(ehsan) → review+
(In reply to Olli Pettay [:smaug] from comment #35)
> Comment on attachment 668913 [details] [diff] [review]
> part.2 alternative (only change the behavior in <input> and <textarea>)

> Don't we need also VK_LEFT/RIGHT tests?

(In reply to Ehsan Akhgari [:ehsan] from comment #36)

> r=me with the added VK_LEFT/VK_RIGHT tests.

Did you mean the |word-wrap: normal;| case? Currently, our <textarea> has |word-wrap: break-word;| in the UA style, though.
(In reply to comment #37)
> (In reply to Olli Pettay [:smaug] from comment #35)
> > Comment on attachment 668913 [details] [diff] [review]
> > part.2 alternative (only change the behavior in <input> and <textarea>)
> 
> > Don't we need also VK_LEFT/RIGHT tests?
> 
> (In reply to Ehsan Akhgari [:ehsan] from comment #36)
> 
> > r=me with the added VK_LEFT/VK_RIGHT tests.
> 
> Did you mean the |word-wrap: normal;| case? Currently, our <textarea> has
> |word-wrap: break-word;| in the UA style, though.

Why does that make a difference?
> Why does that make a difference?

<textarea> is probably never overflown along horizon with default style. <div contenteditable> is overflown, though.
What about <input> ?
(In reply to comment #39)
> > Why does that make a difference?
> 
> <textarea> is probably never overflown along horizon with default style. <div
> contenteditable> is overflown, though.

You could also test that with an input element.
Er, I didn't mean that it's hard to test with <textarea>. I just did confirm that.

Anyway, it should be tested on trunk too, I'll add another patch for the tests.
the difference form the previous patch is whether the doKeyEventTest() has additional argument or not. The change is completely same as the previous patch.
Attachment #670700 - Flags: review?(bugs)
Attachment #670699 - Flags: review?(bugs) → review+
Attachment #670700 - Flags: review?(bugs) → review+
Comment on attachment 668917 [details] [diff] [review]
part.1 Editor should scroll the selection into view after edit even when the editor is specified overflow: hidden;

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
Caused by twitter.com side, not our bug but it's too famous web service which we have this problem.

User impact if declined: 
Users cannot see the inputted text which is overflown from the editor due to not to scroll the caret position automatically. CJK text can input only 70 characters in the editor of twitter.com. I see a lot of complain in fxinput and Army of Awesome from Japanese users.

Testing completed (on m-c, etc.):
The patches were landed on m-c a week ago.

Risk to taking this patch (and alternatives if risky):
If there were some bugs, users could scroll <div> elements which are specified overflow: hidden;. But probably users don't complain such regressions. Probably web designers do.

String or UUID changes made by this patch: 
UUID isn't changed but adding a const to nsISelectionController for a new option for scrollSelectionIntoView(). New flag must be safe. I don't think addon developers use 0xFFFFFFFF to the argument.
Attachment #668917 - Flags: approval-mozilla-beta?
Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
See above comment.

User impact if declined: 
Users cannot scroll overflow:hidden; editor by arrow keys (i.e., moving caret doesn't cause scrolling the editor in twitter.com).

Testing completed (on m-c, etc.): 
Never. This is made only for beta for lower risk than the part.2 for m-c. If we took the patch for m-c, it could cause some regressions without editors. But this patch make editors scroll only when <input> or <textarea> receives caret moving commands.

Risk to taking this patch (and alternatives if risky):
I have no idea for the regressions which this patch would cause.

String or UUID changes made by this patch: 
Nothing.
Attachment #668913 - Flags: approval-mozilla-beta?
Comment on attachment 670700 [details] [diff] [review]
part.3 Add horizontal scroll tests (for beta)

[Approval Request Comment]
Testing completed (on m-c, etc.): 
Today, this was landed to m-i.

Risk to taking this patch (and alternatives if risky): 
Nothing. This just adds a test for part.2.

String or UUID changes made by this patch:
Nothing. Only changes the new test.
Attachment #670700 - Flags: approval-mozilla-beta?
So have we contacted twitter about the change?
(In reply to Olli Pettay [:smaug] from comment #49)
> So have we contacted twitter about the change?

*I* have never tried it. I don't have any idea to fix the issue on the twitter side, though. They have stopped expanding the editor for the contents. That caused this bug. I don't know the reason but it's difficult to think they will revert the change because it probably has some merit.
Web sites do revert changes if they break functionality.
We need to evangelize here.

Could you file a new evangelism bug. We should figure out who to contact @twitter and whether they
could fix this issue on their side.
(In reply to Olli Pettay [:smaug] from comment #51)
> Web sites do revert changes if they break functionality.
> We need to evangelize here.
> 
> Could you file a new evangelism bug. We should figure out who to contact
> @twitter and whether they
> could fix this issue on their side.

filed bug 801526.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #47)
> Risk to taking this patch (and alternatives if risky):
> I have no idea for the regressions which this patch would cause.

We can't take a patch with unknown risk. What's the worst case scenario here Masayuki/Ehsan?
I would recommend against taking this patch on beta.  This is not small and definitely not risk free and I don't see why the risk here would be acceptable to beta.
Attachment #668913 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Attachment #668917 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment on attachment 668917 [details] [diff] [review]
part.1 Editor should scroll the selection into view after edit even when the editor is specified overflow: hidden;

oops - just caught up - taking it back.
Attachment #668917 - Flags: approval-mozilla-beta+ → approval-mozilla-beta?
Attachment #668913 - Flags: approval-mozilla-beta+ → approval-mozilla-beta?
Wontfixing for Beta based on Ehsan's risk assessment, sounds like we can wait for 18 to come with the fix.
Attachment #668913 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Attachment #668917 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
Attachment #670700 - Flags: approval-mozilla-beta? → approval-mozilla-beta-
(In reply to Alex Keybl [:akeybl] from comment #53)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #47)
> > Risk to taking this patch (and alternatives if risky):
> > I have no idea for the regressions which this patch would cause.
> 
> We can't take a patch with unknown risk. What's the worst case scenario here
> Masayuki/Ehsan?

Hmm, I meant that "I have no idea of possible regressions because of very simple change".

(In reply to Ehsan Akhgari [:ehsan] from comment #54)
> I would recommend against taking this patch on beta.  This is not small and
> definitely not risk free and I don't see why the risk here would be
> acceptable to beta.

Oh, I'd like you to take objection to it at requesting tracking beta...
(In reply to comment #57)
> (In reply to Ehsan Akhgari [:ehsan] from comment #54)
> > I would recommend against taking this patch on beta.  This is not small and
> > definitely not risk free and I don't see why the risk here would be
> > acceptable to beta.
> 
> Oh, I'd like you to take objection to it at requesting tracking beta...

I would also like this to get fixed on beta very much, but I am not comfortable with the risk of the existing patch on beta (and unfortunately I can't think of a simpler solution either.)  :(
Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0

Verified in 18 beta 3 - Ubuntu 12.04, Mac OS 10.8, Windows 7.

Could reproduce the initial problem with twitter's input box in 17. Could no longer reproduce in 18b3. Scrolling, typing, focus -all looks good. Same as Chrome in terms of behavior.
Keywords: verifyme
QA Contact: virgil.dicu
Sadly we didn't get this into 17 and it doesn't meet ESR criteria for security-centric dot releases. If a number of ESR users call out this issue as seriously impacting their deployments we can revisit, but for now calling it a wontfix for both ESR.
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.