Closed
Bug 674323
Opened 13 years ago
Closed 13 years ago
convert most eventutils.js functions to use SpecialPowers
Categories
(Testing :: Mochitest, defect)
Testing
Mochitest
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla10
People
(Reporter: jmaher, Assigned: jmaher)
References
Details
(Whiteboard: [specialpowers][inbound])
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
ted
:
review+
|
Details | Diff | Splinter Review |
EventUtils.js has a lot of functions that still use SpecialPowers. This is a cleanup of everything that doesn't send and event.
Assignee | ||
Comment 1•13 years ago
|
||
Assignee: nobody → jmaher
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•13 years ago
|
||
updated patch to fix issues on try server. This patch allows for a green run on try server.
Attachment #548553 -
Attachment is obsolete: true
Attachment #548836 -
Flags: review?(ted.mielczarek)
Comment 3•13 years ago
|
||
Comment on attachment 548836 [details] [diff] [review]
convert eventutils.js to specialPowers (1.5)
Review of attachment 548836 [details] [diff] [review]:
-----------------------------------------------------------------
This is r- just for the getEvent stuff, the rest looks fine.
::: layout/forms/test/test_bug549170.html
@@ +33,5 @@
>
> function mouseHandler(aEvent)
> {
> gNumberOfMouseEventsCatched++;
> + aEvent = SpecialPowers.getEvent(aEvent);
I don't like this. Can you talk to smaug about why this doesn't work without the wrapper instead of adding this hack? I don't think we should add hacks for individual tests like this.
::: testing/mochitest/specialpowers/content/specialpowers.js
@@ +97,5 @@
> + if (aWindow == this.window)
> + return this.DOMWindowUtils;
> +
> + return bindDOMWindowUtils(aWindow);
> + },
I really don't like this, but if you can't get things to work without it I guess we'll take it.
::: testing/mochitest/tests/SimpleTest/EventUtils.js
@@ +674,5 @@
> + } else if ("SpecialPowers" in parent) {
> + return parent.SpecialPowers.getDOMWindowUtils(aWindow);
> + } else if (window.opener != null && "SpecialPowers" in window.opener) {
> + return window.opener.SpecialPowers.getDOMWindowUtils(aWindow);
> + }
This is really crazy. Can you file a followup bug on trying to sort out if we can make this less crazy? Maybe we need some platform hackers to figure out why we don't always get SpecialPowers set up correctly.
Attachment #548836 -
Flags: review?(ted.mielczarek) → review-
Updated•13 years ago
|
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
Assignee | ||
Comment 4•13 years ago
|
||
updated patch, no getEvent stuff anymore. Green on try server.
Attachment #548836 -
Attachment is obsolete: true
Attachment #565916 -
Flags: review?(ted.mielczarek)
Comment 5•13 years ago
|
||
Comment on attachment 565916 [details] [diff] [review]
convert eventutils.js to specialPowers (2.0)
Review of attachment 565916 [details] [diff] [review]:
-----------------------------------------------------------------
::: testing/mochitest/tests/SimpleTest/EventUtils.js
@@ +530,5 @@
> + } else if ("SpecialPowers" in parent && parent.SpecialPowers != undefined) {
> + return parent.SpecialPowers.getDOMWindowUtils(aWindow);
> + } else if (window.opener != null && "SpecialPowers" in window.opener) {
> + return window.opener.SpecialPowers.getDOMWindowUtils(aWindow);
> + }
This stuff still makes no sense to me, but I'm past caring about it.
Attachment #565916 -
Flags: review?(ted.mielczarek) → review+
Assignee | ||
Comment 6•13 years ago
|
||
when we do window.open(data:...) or open up bookmark manager, we do not have access to specialpowers. So the end result is we need to ensure all test code has access to SpecialPowers. It would be nice to eventually clean all this up, but there are a lot of special cases.
Comment 7•13 years ago
|
||
Can we maybe open a bug to track that issue? It doesn't have to block this stuff landing, but it'd be good to figure out the root cause eventually.
Comment 8•13 years ago
|
||
(In reply to Joel Maher (:jmaher) from comment #6)
> when we do window.open(data:...) or open up bookmark manager, we do not have
> access to specialpowers. So the end result is we need to ensure all test
> code has access to SpecialPowers. It would be nice to eventually clean all
> this up, but there are a lot of special cases.
I don't believe this is true any longer after bug 681392. Can you confirm?
Assignee | ||
Comment 9•13 years ago
|
||
I found a few scenarios were we did rely on window.parent. I documented them in the patch and removed the window.opener clause.
Assignee | ||
Comment 11•13 years ago
|
||
Whiteboard: [specialpowers] → [specialpowers][inbound]
Comment 12•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
You need to log in
before you can comment on or make changes to this bug.
Description
•