Open Bug 718868 Opened 8 years ago Updated 8 years ago

[SeaMonkey] mochitest-plain-4: test_reftests_with_caret.html > bug682712-1.html (or bug682712-1-ref.html) causes "JavaScript strict warning: chrome://communicator/content/utilityOverlay.js, line 1323: reference to undefined property e.button"

Categories

(SeaMonkey :: UI Design, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

People

(Reporter: sgautherie, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: helpwanted)

(Noticed while investigating bug 717868.)

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1326804272.1326805142.11349.gz&fulltext=1
OS X 10.5 comm-central-trunk debug test mochitests-4/5 on 2012/01/17 04:44:32
{
1786 INFO TEST-PASS | /tests/layout/base/tests/test_reftests_with_caret.html | Reftest http://mochi.test:8888/tests/layout/base/tests/bug664087-2.html
...
JavaScript strict warning: chrome://communicator/content/utilityOverlay.js, line 1323: reference to undefined property e.button
...
WARNING: failed to load URL: file /builds/slave/comm-cen-trunk-osx-dbg/build/mozilla/content/html/content/src/nsGenericHTMLElement.cpp, line 3335
}

This bug is about the "JavaScript strict warning".
I'll see about "WARNING: failed to load URL" after that one is fixed, just in case the former would solve the latter. (Though I don't expect that.)


http://mxr.mozilla.org/comm-central/source/suite/common/utilityOverlay.js#1296
{
1322   // ignoreButton allows "middle-click paste" to use function without always opening in a new window.
1323   var middle = !ignoreButton && e.button == 1;
}
At first glance, it looks +/- the same as Firefox code, so I don't know what to look for.

Fwiw:
http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/bug682712-1.html?force=1
http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/bug682712-1-ref.html?force=1
http://mxr.mozilla.org/comm-central/ident?i=whereToOpenLink
http://mxr.mozilla.org/comm-central/search?string=whereToOpenLink&case=on
I can't reproduce this in any of my (non-Mac) builds, although I did observe some strange behaviour (non-windows tests passing in Windows but only if my window wasn't big enough to show the entire test at once...)

It's possible that the the intention is there to work with keyboard events, but the caller is either unaware that they have a keyboard event or that they need to set ignoreButton in that case. However it is difficult to find out who the caller might be.
You need to log in before you can comment on or make changes to this bug.