UI bug(?): can't prevent tab switching

[ketmar]

in my tab switching script (userChrome/extension) i used to cancel tab "keypress" event to stop UI from switching tabs on ctrl+tab. now UI seems to not use "keypress" event for that anymore, and i can't prevent tab switching. this can potentially break alot of tab switching extensions, 'cause there were no other documented way to block ctrl+tab in UI, and now it seems that there is no way to do it at all.

is this just an oversight, a design change, or... i mean -- what is the blessed way to write my own ctrl-tab switcher for Tycho?

for now i'm just using `setTimeout()` to let standard UI do it's switch, and then do my own switch. this is terrible, just terrible. it does ugly tab jumps, and (which is much worser) it hits not-yet-loaded tabs, triggering loading.

[ketmar]

some js code to show what i mean:

Code: Select all

let ctrlTabPressed = false;

function cancelEvent (evt) {
  if (typeof(evt) === "object") {
    if (typeof(evt.preventDefault) === "function") evt.preventDefault();
    if (typeof(evt.stopPropagation) === "function") evt.stopPropagation();
    if (typeof(evt.stopImmediatePropagation) === "function") evt.stopImmediatePropagation();
  }
}


function isCtrlTab (evt) (evt.keyCode == evt.DOM_VK_TAB && evt.ctrlKey && !evt.altKey && !evt.shiftKey && !evt.metaKey);


window.addEventListener("keydown", function (evt) {
  // ctrl+tab should cycle tabs
  if (isCtrlTab(evt)) {
    cancelEvent(evt);
    ctrlTabPressed = true;
    // ...here i'm doing my own complicated bussiness...
    //gBrowser.selectedTab = myNewTab; // this switch will be overriden by standard UI
    setTimeout(function () { gBrowser.selectedTab = myNewTab; }, 150); // gum non-solution!
  }
}, false);


window.addEventListener("keyup", function (evt) {
  // ctrl+tab should cycle tabs
  if (isCtrlTab(evt)) {
    cancelEvent(evt);
  } else if (evt.keyCode == evt.DOM_VK_CONTROL) {
    // if we done some cycling, fix tab order
    if (ctrlTabPressed) {
      ctrlTabPressed = false;
    }
  }
}, false);


// disable the default behavior
window.addEventListener("keypress", function (evt) {
  if (isCtrlTab(evt)) {
    // this USED to work to cancel ctrl+tab switching, and now it doesn't
    // trying to cancel just tab when `ctrlTabPressed` and reset it here instead of "keyup" doesn't work too
    // besides, this way was OK in Pale Moon 26.
    cancelEvent(evt);
  }
}, false);

this used to work as it is (and still works) in Pale Moon 26. actually, i took the idea from some Ff extension that does ctrl+tab replacing, and was using that for a long time. now it doesn't work anymore, and there is no other way to stop standard UI from processing ctrl+tab.

p.s. just in case. i'm not ranting, just pointing to possible breakage, and asking for some advice. ;-)

[GMforker]

See bug #1008772

[ketmar]

thank you. in other words: mozilla broke even such a simple thing. deliberately. now there is NO WAY to write correct ctrl+tab replacement extension. great. thank you, mozilla, without you my life was dull and boring.

[Moonchild]

That bug wasn't ported with the rewrite of key handling in v26 on purpose. I should probably make a note to revert it in Tycho.

[ketmar]

thank you. it will be great to be able to prevent default ctrl+tab again. ;-)

[GMforker]

See also Add Option or White/Blacklist to Disable Keyboard Shortcut Hijacking

[ketmar]

tbh, for me it looks like two completely different problems. my script has chrome rights, and that bug is about web scripts, which are in sandbox. i didn't looked at UI code, but i imagine that if sandboxed scripts can steal keyboard events from chrome scripts, it is all wrong, from the top to the bottom.

2all: please note that i'm not talking about current Tycho codebase, i am just thinking out loud.

[Moonchild]

The problem is that there is no easy way to determine whether key events that were fired are caught by a chrome script or by a content script. Key events are key events.

The github issue and this thread are exactly the same issue, but two different desired behaviors as a result.

There is a solution for this extension issue though: use keydown events instead of keypress events.