Ticket #2127 (closed New Feature: fixed)

Opened 7 years ago

Last modified 5 years ago

Disable scrollbar of editor parent while dialog is active

Reported by: MarkWB Owned by: martinkou
Priority: Normal Milestone: FCKeditor 2.6.2
Component: General Version: SVN (FCKeditor) - Retired
Keywords: Confirmed Review+ Cc:

Description

It would be nice to have again what effectively was a feature before 2.6. In other words, it would be nicer if somehow the vertical scroll bar of the main browser window could be disabled while a dialog is active. This is because the mouse wheel can now scroll away the whole dialog (and editor window) after a scroll bar within a dialog reaches its limit and the parent page containing the editor instance is taller than the browser window. (a little bit annoying) This of course couldn't happen from a popup.

The following:

window.document.body.style.overflow='hidden';

could work for IE, but unfortunately not FF. FF scrolls to the top before disabling the scroll bar. I'm hoping you can think of a more elegant solution.

Attachments

2127.patch (2.0 KB) - added by martinkou 7 years ago.
2127_2.patch (2.3 KB) - added by martinkou 6 years ago.
2127_3.patch (1.8 KB) - added by martinkou 6 years ago.

Change History

comment:1 Changed 7 years ago by w.olchawa

  • Keywords Confirmed added

comment:2 Changed 7 years ago by martinkou

  • Owner set to martinkou
  • Status changed from new to assigned

Changed 7 years ago by martinkou

comment:3 Changed 7 years ago by martinkou

  • Keywords Review? added

comment:4 Changed 7 years ago by MarkWB

Line 199 of patch seems to break selection for FF2. Works alright for IE7.

To reproduce with FF: 1) Move caret anywhere except the beginning 2) Use a dialog to insert content; such as a smiley, special char, or using a Paste dialog (not ctrl-V).

Content will get inserted at the beginning.

comment:5 Changed 7 years ago by MarkWB

Another slight flaw for only FF. Button state for whatever dialog you open remains in hover over state after the dialog has closed. It'll correct itself after it's been hovered over again, but isn't right on dialog close. This doesn't happen without the patch.

comment:6 Changed 7 years ago by alfonsoml

  • Keywords Review- added; Review? removed

Besides those issues, is there any reason why you are checking the compatMode instead of calling FCKTools.IsStrictMode ?

comment:7 Changed 6 years ago by martinkou

The compatMode thing was a mistake, as I didn't remember the FCKTools.IsStrictMode() check at the moment I coded the patch. But that can be easily corrected.

The selection removal issue is a much bigger obstacle though, because this is a browser bug. I couldn't really think of any simple workaround for that, except for porting the save/restore selection logic (i.e. FCKSelection.Save(), FCKSelection.Restore(), etc.) for IE to Firefox. That approach would has its own problems however - e.g. restoring control selections in Firefox would be difficult (if not impossible).

Changed 6 years ago by martinkou

comment:8 Changed 6 years ago by martinkou

  • Keywords Review? added; Review- removed

It seems there's no short term workaround for Firefox's selection clearing bug. Also I've noticed that Safari on Mac doesn't immediately restore the scrollbar after dialog close - it would only appear again if the user scrolled with his mouse wheel.

I'm proposing another patch which would add the clear scrollbar feature to IE and Opera only. For the other browsers, I'll file a bug report to them and wait for them to be fixed first. Also, FCKTools.IsStrictMode() is used instead of checking document.compatMode.

comment:9 Changed 6 years ago by fredck

  • Keywords Review- added; Review? removed

After some discussions with Martin on IRC today, we found out that this problem can be fixed by using "position:fixed" in the dialog, instead of "position:absolute". It works well for Firefox, Safari, Opera and IE7.

Only IE6- would still present the current behavior, and we have decided to not include further code in the dialog system just to handle that browser. After all, this issue is a small annoyance, but don't make it impossible to use the editor.

Changed 6 years ago by martinkou

comment:10 Changed 6 years ago by martinkou

  • Keywords Review? added; Review- removed

comment:11 Changed 6 years ago by fredck

  • Keywords Review+ added; Review? removed

comment:12 Changed 6 years ago by martinkou

  • Status changed from assigned to closed
  • Resolution set to fixed

Fixed with [2094].

Click here for more info about our SVN system.

Note: See TracTickets for help on using tickets.
© 2003 – 2012 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy