[Android] Dialog windows open in an incorrect place on a page and cannot be moved

[Anna Tomanek]

Tested on Samsung Galaxy S, Android 4.2.1 (Jelly Bean), CKEditor 4.0.1 samples for the Standard preset, replacebycode and inline samples.

After a toolbar button is clicked, editor dialog windows seem to open in a pre-determined place on the page, outside the editor window, and with a zoomed-in page it they are out of sight for the user. From the user's perspective it looks like something is wrong: the page becomes grayed out, but he/she needs to zoom out to see the dialog window.

It looks like the dialog windows are centered on the page or opened with a pre-determined offset that ignores the zoom level.

What is more, they cannot seem to be moved. Holding the title bar and dragging it does not do anything (it actually scrolls the page). The page below containing the editor is still scrollable. The only thing that seems to change the location of the dialog windows is zooming in and out.

This can also be reproduced in inline mode.

In Firefox 18.0.2 and Chrome 18.0.1025469 the dialog window moves around the page, too, and its location is also affected by whether the virtual keyboard is open or not.

[Anna Tomanek]

Another problem is that with zooming in and out (that is needed in order to find the dialog window on the page) the part of the window that was out of the viewport may be cut and one needs to force redrawing it by e.g. clicking another tab of the same dialog window.

[Piotr Jasiun]

Still a valid bug on Android 4.4.2 with Chrome 33. Also such bug exists on iOS (#8313 and #11721). I believe that these are two separate bugs:

• dialogs are in the wrong position because window measure script does not consider zooming,
• it is not possible to drag dialog because of general drag & drop issue on mobile (#11722).

[Szymon Kupś]

I did some research about this, and there are couple reasons why this behavior is happening:

• Dialogs are positioned with JavaScript using listeners on window's resize event. When software keyboard is opened (to enter data into the dialog's fields) window size is changed and dialog is re-positioned again.
• position: fixed is used in order to center dialog windows. When zooming in and out dialogs are scaled and positioned independently from document. It creates false illusion that dialog 'moves' around the screen when zooming. This is especially annoying when browser is automatically zooming into dialog's fields.

I've pushed ​branch:t/10082.
Proposed solution fixes some of the navigating issues. It's a new plugin that patches dialog plugin behavior (can be used optionally when mobile support is needed the most) :

• Dialogs are positioned using CSS, no listener is attached to window resize event. When software keyboard is shown no re-positioning is performed.
• position:fixed is changed to position:absolute. When zooming is performed dialog is scaled proportionally to current document.

Unfortunately this solution has its flaws:

• Dialog navigation is performing better but there are situations (especially on big zoom levels) when its not perfect.
• Dialog dragging is disabled.
• position:absolute has disadvantages:
  • Dialog is positioned according to parent's container not the window. There are situations when document body is not occupying whole window area and then dialog is not positioned on the window's center.
  • Dialog is scrolled with the document.
• Solution is not compatible with IE Quirks Mode.

I am putting this issue on review for now. Comments and new ideas are more than welcome. If the solution will be acceptable, plugin name and documentation will be needed.

[Tade0]

Overall this new plugin works is better than the regular dialog plugin, unfortunately there's one "but":

If the screen is oriented vertically and the dialog is opened rotating the device makes the dialog disappear from view, because it's positioned too low.

This could probably be fixed by repositioning the dialog on orientation change.

[Marek Lewandowski]

Moving to 4.6.2 minor release, as 4.6.1 is mostly about polishing 4.6.0.

[Marek Lewandowski]

This issue is not a priority ATM, however it would be nice to have it fixed in the future - adding to our todo list.