Closed Bug 820807 Opened 13 years ago Closed 12 years ago

Test failure "Suite progress indicator is red - got 'false'" in addons/ide@seleniumhq.org/ tests

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Product:
Mozilla QA Graveyard
Component:
Mozmill Tests
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox20 fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox20 --- fixed

People

(Reporter: AndreeaMatei, Assigned: davehunt)

References

(
URL
)

Details

(Keywords: regression, Whiteboard: [mozmill-test-failure])

Attachments

(1 file)

Upgrade version of Selenium IDE used by add-on tests to 1.10.0. v1.0
985 bytes, patch
whimboo
: review+
Details | Diff | Splinter Review
We have 3 testruns failing with this error, followed by: "could not validate element Elem instance. with value 1" This happens on OS X so far, all versions, with Nightly. http://mozmill-ci.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db13091f http://mozmill-ci.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db12e860
URL: http://mozmill-ci.blargon7.com/#/addo...
status-firefox20: --- → affected
Whiteboard: [mozmill-test-failure]
Sounds like a regression in Firefox or the Selenium IDE extension.
Keywords: regression
OS: Mac OS X → All
I can reproduce issues with Selenium IDE manually. As the extension has not changed this must be related to Firefox. When manually launching Selenium IDE in Nightly I see the following error in the console: Timestamp: 12/12/12 4:04:10 PM Error: NS_ERROR_XPC_CANT_GET_PARAM_IFACE_INFO: Cannot find interface information for parameter arg 1 [nsISeleniumIDEGenericAutoCompleteSearch.setCandidates] Source File: chrome://selenium-ide/content/treeView.js Line: 189 Here's the pushlog of changes between last good and first bad: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4dfe323a663d&tochange=634180132e68 I'll use the tinderbox builds to narrow down the regression range.
Assignee: nobody → andrei.eftimie
Andrei, please use tinderbox builds to narrow down the range even more. You can find those here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/
I have narrowed this down to a merge from inbound: http://hg.mozilla.org/mozilla-central/rev/87f8165c5a0b Please continue with the mozilla-inbound tinderbox builds.
I've found the changeset responsible for the regression: rev 45bbc96e059f PASSED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db20c5c7 rev 057218b30dcb PASSED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db20f691 rev 668141ff2577 PASSED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db2137b9 The first bad revision is: changeset: 115578:8d00a8bf1508 user: Trevor Saunders <trev.saunders@gmail.com> date: Sun Dec 09 13:40:46 2012 -0500 summary: bug 819940 - remove nsISupportsArray::EnumerateBackwards() r=ehsan rev 8d00a8bf1508 FAILED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db22de64 rev 4528be937f5c FAILED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db229d76 rev f5e76b86f70c FAILED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db22769a rev b901ea202aeb FAILED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db2105bb rev 87f8165c5a0b FAILED - http://mozmill-crowd.blargon7.com/#/addons/report/a11aa7b15f4e571fd6fe21a2db20e7c1 What steps should we take now?
(In reply to Dave Hunt (:davehunt) from comment #8) > The failure in the addon mentioned in comment 3 references this line: > http://code.google.com/p/selenium/source/browse/trunk/ide/main/src/content/ > treeView.js#189 Which is: > Editor.GENERIC_AUTOCOMPLETE.setCandidates(XulUtils.toXPCOMString(this.editor.getAutoCompleteSearchParam("commandAction")), > --> >XulUtils.toXPCOMArray(commands)); Ehsan and Trevor, is that a valid failure given the changes introduced by bug 819940 or should that not have addressed addon compat? Is it our fault or should the code of the Selenium IDE extension be updated?
Blocks: 819940
Ehsan: Any thoughts on why bug 819940 would have regressed this addon's functionality? I can't see any calls to EnumerateForwards of EnumerateBackwards in the addon's source.
I don't know what the toXPCOMArray method there does. The methods that were removed in bug 819940 were noscript, so I don't know how this add-on can be using them. Trevor, can you take a look please? Thanks!
Assignee: andrei.eftimie → trev.saunders
(In reply to comment #12) > The implementation for toXPCOMArray can be found here: > http://code.google.com/p/selenium/source/browse/trunk/ide/main/src/content/xul-utils.js#35 Hmm, so it looks like AppendElement is broken for some reason...
(In reply to Ehsan Akhgari [:ehsan] from comment #13) > (In reply to comment #12) > > The implementation for toXPCOMArray can be found here: > > http://code.google.com/p/selenium/source/browse/trunk/ide/main/src/content/xul-utils.js#35 > > Hmm, so it looks like AppendElement is broken for some reason... yeah, but that seems crazy, since we must have tree view tests and stuff that use appendElement()... What exactly do I need to do to reproduce this? just install the ide extension thing and open it somehow?
(In reply to Trevor Saunders (:tbsaunde) from comment #14) > What exactly do I need to do to reproduce this? just install the ide > extension thing and open it somehow? To see that do the following: 1. Install the extension from http://release.seleniumhq.org/selenium-ide/editor/1.7.1/selenium-ide-editor-1.7.1.xpi 2. Open the IDE via Tools | Selenium IDE After step 2 the before mentioned error should appear in the Error Console and the window stops working.
If it turns out that it is a failure in Firefox we should better file a new bug given that this one here is for our failing Mozmill test and we would like to keep it in this component.
Assignee: trev.saunders → nobody
ok, so I seem to be able to reproduce the exception on linux. for some reason xpconnect throws in XPCWrappedNative.cpp:2840 but I don't know nearly enough about xpconnect / xpt stuff to debug further without someone I can ask about that stuff so I'll leave that for tomorrow.
Maybe Bobby knows?
(In reply to Ehsan Akhgari [:ehsan] from comment #18) > Maybe Bobby knows? So, the addon defines an interface that involves methods taking a nsISupportsArray argument. bug 819940 changed the iid of that interface, so I wonder if the addon's xpt needs regenerated?
> So, the addon defines an interface that involves methods taking a > nsISupportsArray argument. bug 819940 changed the iid of that interface, so > I wonder if the addon's xpt needs regenerated? yes, it turns out the xpt does need to be regenerated, so try rebuilding the addon and trying again?
Would the add-on need two xpt one before the change and one after? Or how would older builds behave once the xpt has been updated?
(In reply to Henrik Skupin (:whimboo) from comment #21) > Would the add-on need two xpt one before the change and one after? Or how > would older builds behave once the xpt has been updated? I believe that an xpt generated with the new id for nsISupportsArray wouldn't work with firefox built before bug 819940.
(In reply to Trevor Saunders (:tbsaunde) from comment #22) > (In reply to Henrik Skupin (:whimboo) from comment #21) > > Would the add-on need two xpt one before the change and one after? Or how > > would older builds behave once the xpt has been updated? > > I believe that an xpt generated with the new id for nsISupportsArray > wouldn't work with firefox built before bug 819940. however this wouldn't be an issue if the addon switches to nsIArray / nsIMutableArray which it should really do anyway.
The other solution is to use forward declarations instead of includes. Unless you're inheriting from another interface, you don't need to include it. nsIAutoCompleteSearch.idl is a good example of this; it uses nsIAutoCompleteResult but doesn't include it. When this gets compiled to an XPT then the interface's UUID doesn't get included of course. However this is not a problem for JS callers because XPConnect can match it based on the interface name.
Assignee: nobody → mario.garbi
Assignee: mario.garbi → andrei.eftimie
Dave has to take care about this issue. It's not on any of our sprints so not sure why Mario and Andrei have been assigned here.
Assignee: andrei.eftimie → dave.hunt
Status: NEW → ASSIGNED
Given that it is blocked by an external tool I will add the qa-automation-blocked entry. Dave will have an update for us soon.
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure][qa-automation-blocked]
(In reply to neil@parkwaycc.co.uk from comment #24) > The other solution is to use forward declarations instead of includes. > Unless you're inheriting from another interface, you don't need to include > it. nsIAutoCompleteSearch.idl is a good example of this; it uses > nsIAutoCompleteResult but doesn't include it. > > When this gets compiled to an XPT then the interface's UUID doesn't get > included of course. However this is not a problem for JS callers because > XPConnect can match it based on the interface name. I removed the include and recompiled locally. So far this seems to be working well. I will continue to test and hopefully release a new version of the addon soon.
Attachment #693334 - Flags: review?(hskupin)
Attachment #693334 - Flags: review?(andreea.matei)
Attachment #693334 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill-test-failure][qa-automation-blocked] → [mozmill-test-failure]
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: