(In reply to Jonas Allmann [:jallmann] from comment #5)
Created attachment 9041802 [details] [diff] [review]
Work in progress diff.
I'm still tring to wrap my head around this and how commands work in the first place.
I attached a diff of what I'm doing so far. It seems to work at firt glance, the middle-click funtionality is preserved for the buttons I've tested. But I have a few doubts and my approach seems too easy to be correct.
- Can I just change the behaviour of the
oncommand attribute of these elements without breaking their behaviour when the command is not triggered by
checkForMiddleClick() but some other event that is not carrying the correct
Unfortunately probably no, because then we'll pass
null as the event in the other cases, which is likely to break things in some places. It would be better to change the contents of the event handler (perhaps not directly in the XUL markup but in the thing they call, e.g.
gContextMenu.reload() implementation in nsContextMenu.js ) to check
event.sourceEvent instead of just
event. In some cases it might be OK to pass the event as
event.sourceEvent || event from the oncommand handler, though that feels a bit hacky.
- Related to the first question: Some elements using
checkForMiddleClick() do not have an
oncommand attribute themselves but reference a
command. Changing this command to use
event.sourceEvent instead of
event will break correct handling of situations where the command is not triggered by a middle click, am I correct? Example:
<toolbarbutton id="back-button" class="toolbarbutton-1 chromeclass-toolbar-additional"
<command id="Browser:BackOrBackDuplicate" oncommand="BrowserBack(event);" disabled="true">
I assume changing this to
<command id="Browser:BackOrBackDuplicate" oncommand="BrowserBack(event.sourceEvent);" disabled="true">
would break the command's behaviour in situations other than middle-clicks.
Would it be a solution to check if
event carries a
sourceEvent and use the latter only if present?
Yeah, so the if condition I suggested would work, but like I said earlier, I think it'd be neater to put that check in the
BrowserBack implementation (in this case) than inline in the
Or do I need to adapt each of the funcions called in any of the commands, like
BrowserBack() in the example, to handle both types of situations correctly?
So this, ideally. :-)