Opening new issue as per request at http://drupal.org/node/668104#comment-2433276

The overlay does not fully respect key handlers. Ctrl+click on a link in the toolbar to open it in a new tab. In that new tab, many keyboard functions do not work properly.

eg 1. ctrl+t does not open a new tab.
eg 2. ctrl+w does not close the tab.

When navigating the overlay in a single tab this problem is not present.

Firefox 3.5, Ubuntu.

CommentFileSizeAuthor
#16 overlaykeyhandlers.patch1.03 KBcasey
#13 overlaykeyhandlers.patch789 bytescasey
#7 overlaykeyhandlers.patch766 bytescasey
#4 overlaykeyhandlers.patch862 bytescasey

Comments

casey’s picture

casey commented

I think this issue has same cause as #671276: Overlay blocks my scrollbar; jQuery UI dialog's modal overlay is catching all events.

I'll post a patch today.

David_Rothstein’s picture

David_Rothstein commented

To clarify, in order to experience this bug with ctrl-click it seems like you would need to apply the patch at #668104: Make overlay respect other click handlers first -- otherwise ctrl-click doesn't even open a new tab currently.

However, it's an independent bug, since I can reproduce it by opening a tab in other ways (in Firefox, right clicking and choosing the "open link in new tab" option).

For what it's worth, this bug only seems to occur when the mouse does not have focus on the overlay child window. That is, I'm noticing that if you click on the overlay iframe first, then ctrl+t, ctrl+w, etc start to work again. Not sure if that is just an artifact of the types of events that jQuery UI is catching, but thought I'd mention it.

casey’s picture

casey commented

This for sure is caused by jQuery UI dialog's modal overlay. I hoped the patch you mention went in yesterday. I'll post a patch after that one gets fixed.

casey’s picture

casey commented
Status: Active » Needs review
StatusFileSize
new overlaykeyhandlers.patch862 bytes

This makes it work again.

When you focus displaced regions like the toolbar, you however still can't use those keycombinations. The overlay is modal so this behavior is ok I think.

mrfelton’s picture

mrfelton commented
Status: Needs review » Needs work

@casey: I'm not sure exactly what you are saying about it being ok that key handlers don't work when focusing specific areas is right. IMO ctrl+w should close the tab regardless of what is displayed on the page or what is focused.

The behaviour with this patch is better, but still not perfect.

1. Ctrl+click on the structure tab.
2. Switch to the tab very quickly and try closing it with ctrl+w before it has finished loading - it works (sometimes - seems to depend at exactly which point you try the key combo)

1. Ctrl+click on the structure tab.
2. Switch to the tab and this time wait until the page has fully loaded. Now, ctrl+w does nothing.
3. Click somewhere within the overlay
4. Try ctrl+w again and now it works.

So in order to be able to close the tab easily I have to either be very quick or I have to click in a specific part of the browser window first (ie. in the overlay). I find this very annoying.

mrfelton’s picture

mrfelton commented

To further clarify what I am experiencing. It seems that if I switch to the new tab before it has finished loading, then I can close with the key combo. If I wait until the new tab has completely finished loading and then switch to it, the key combo doesn't work unless I click within the browser window of the new tab first.

casey’s picture

casey commented
StatusFileSize
new overlaykeyhandlers.patch766 bytes

This one does make it work right?

Problem is this solution has possible incompatibilities with other modules; all keypress events are handled now. I can't come up with a situation/module that'll be a problem right now, so maybe we can do this anyway.

casey’s picture

casey commented
Status: Needs work » Needs review
mrfelton’s picture

mrfelton commented
Status: Needs review » Needs work

I don't see a difference. Same behaviour.

casey’s picture

casey commented

What browser are you using?

mrfelton’s picture

mrfelton commented

ps. The problem with ctrl+t that I described in my first post is fixed with both these patches. Only ctrl+w is the problem now (although those are the only two key combos I have checked).

mrfelton’s picture

mrfelton commented

Firefox 3.5.6, Ubuntu Karmic

casey’s picture

casey commented
Status: Needs work » Needs review
StatusFileSize
new overlaykeyhandlers.patch789 bytes

How about this one

mrfelton’s picture

mrfelton commented

Seems to have done it - much better :) Thanks.

aspilicious’s picture

aspilicious commented

Windows 7, chrome 4 dev

Works for me!
If green back to rtbc!

casey’s picture

casey commented
StatusFileSize
new overlaykeyhandlers.patch1.03 KB

Added comment.

I suggest we try this approach as it's not very likely that this will collide with other keypress handlers. ui.dialog's keypress handler is bound to $(document) so it'll only block handlers that are bound to $(window); keypress handlers that are bound to $(document) are trigger anyway.

mrfelton’s picture

mrfelton commented

That one works for me too.

moshe weitzman’s picture

moshe weitzman commented
Status: Needs review » Reviewed & tested by the community

rtbc based on #15

webchick’s picture

webchick
she/they
Primary language English
Location Vancouver 🇨🇦
commented
Status: Reviewed & tested by the community » Fixed

Oh, nice! This has been driving me nuts.

Committed to HEAD.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.