Opened 11 years ago

Closed 11 years ago

#10623 closed Bug (fixed)

[Webkit] Page is scrolled when opening dropdown

Reported by: Piotrek Koszuliński Owned by: Piotrek Koszuliński
Priority: Normal Milestone: CKEditor 4.2.1
Component: General Version: 4.1.2
Keywords: Webkit Cc:


  1. Open some long sample to have a scrollbar (e.g. samples/datafiltering.html).
  2. Scroll few px down.
  3. Open e.g. a font-size dropdown.
  4. Page was scrolled.

First bad commit: git:d0f600ed.

Attachments (1)

go-btn.gif (564 bytes) - added by Slavon 10 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 11 years ago by Piotrek Koszuliński

Status: newconfirmed

comment:2 Changed 11 years ago by Olek Nowodziński

Owner: set to Olek Nowodziński
Status: confirmedassigned

comment:3 Changed 11 years ago by Olek Nowodziński

Revelations (so far):

  • The issue was introduced along with #10361.
  • This single line is a troublemaker
  • A commit git:d0f600ed introduced nothing but an else statement and a conditional setTimeout. In fact the rest of changes (most of the rest) is useless.
  • I'm having some serious problems with JAWS when testing possible solutions. When opening a panel, focus is randomly moved to the top of the page, leaving the panel open and inaccessible for the reader. The similar thing happens when focusing an editable with a mouse. (Chrome 28.0.1500.95). Therefore I'm unable to find a solution that doesn't violate a11y.

comment:4 Changed 11 years ago by Piotrek Koszuliński

Two DUPs were reported: #10718, #10743.

comment:5 Changed 11 years ago by Piotrek Koszuliński

I gave this issue a try and I don't have good news :). I found that focusing this.element ( at any moment will always cause scroll. I even removed that statement completely and focused it later from console and the same happened.

Webkit/Blink seems to scroll the viewport to fit as much of the this.element (which is a div inside panel's iframe) as it can. Scrolling happens most often when opening the styles drop down because it's the longest (so that div element is the highest) - in fact it does not fit in the viewport completely.

So if we need to focus the list element (and I assume we do), we need to find out what are the ways to avoid scrolling when focusing (e.g. we can set the height to 0px?) or we can restore the scroll position as we already do e.g. when focusing pastebin. In fact the second option may be the most stable solution, but not perfect, since not only viewport may be scrolled by the browser.

PS. I've read in #10361 that there were problems with stability and Olek mentions that too. Looking at this code: I don't understand why selected is focused with delay, but this.element is focused immediately. They are in the same frame and selected is a descendant of this.element, so they may be no reason to differentiate this.

Second thing is that it would be worth checking higher timeouts. I often see differences between tested machines (even when using the same browser) which are caused by a different order of events which is happens because of number of micro timeouts (which theoretically are predictable) and DOM events (which completely aren't predictable).

comment:6 in reply to:  5 Changed 11 years ago by Olek Nowodziński

@Reinmar: I spent some time investigating this issue and playing with setTimeout brings nothing more but... more timeout. It's not entirely the timeout thing what we need, I guess. Something else, like the pastebin focus solution could work, but I'd look for simpler solution first.

Still, apart from the UX aspect, there's a11y that makes me worry as we're unable to verify it. I'm eager to see Fred dealing with that first.

comment:7 Changed 11 years ago by Frederico Caldeira Knabben

Owner: changed from Olek Nowodziński to Frederico Caldeira Knabben
Status: assignedreview

I didn't find any good solution for this as well. Any attempt to make it work breaks the a11y side of it.

I've just pushed t/10623, which contains one of the ideas we had on #10361. I'm not a big fan of it, but it can be the only solution for now.

comment:8 Changed 11 years ago by Piotrek Koszuliński

This issue (scrolling) is not critical, so if we cannot quickly find a decent solution, I'd rather postpone it than include insecure hack.

I pushed t/10623b with a simple hack that restores viewport scroll position after focusing element. Isn't this enough?

comment:9 Changed 11 years ago by Piotrek Koszuliński

Owner: changed from Frederico Caldeira Knabben to Piotrek Koszuliński

comment:10 Changed 11 years ago by Olek Nowodziński

Status: reviewreview_passed

comment:11 Changed 11 years ago by Olek Nowodziński

Resolution: fixed
Status: review_passedclosed

Merged t/10623b into master (​git:cff2ba14dde4).

Changed 10 years ago by Slavon

Attachment: go-btn.gif added
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy