Closed
Bug 552594
Opened 15 years ago
Closed 15 years ago
[mozmill] Failure in testOpenInBackground.js when run in Firefox 3.6.x
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: marklocklear, Assigned: whimboo)
References
Details
(Whiteboard: [mozmill-test-failure])
Attachments
(2 files, 8 obsolete files)
927 bytes,
patch
|
u279076
:
review+
|
Details | Diff | Splinter Review |
904 bytes,
patch
|
aaronmt
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100311 Ubuntu/9.10 (karmic) Namoroka/3.6.2pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.2pre) Gecko/20100311 Ubuntu/9.10 (karmic) Namoroka/3.6.2pre
See Litmus test # 8087
https://litmus.mozilla.org/show_test.cgi?searchType=by_id&id=8087&page=1
Reproducible: Always
Steps to Reproduce:
Before running the test open Options (Preferences) | Tabs. Uncheck the entry for "When I open a link in a new tab, switch to it immediately." Close the Options dialog.
1. Open the testcase and use the context menu to load the link with id=1 in a new tab. Switch to that newly opened tab.
2. Again, in the first tab use the context menu to open the link with id=2 in a new tab.
3. If a middle mouse button is present use it to open the link with id=3 in a new tab.
4. Select and close the latest opened tab with id=3.
Actual Results:
When the test runs I can see the 3 tabs open. From left to right they are ordered 1, 2, 3. The expected results in Litmus says the tab order should be 2, 3, 1.
Expected Results:
In step 2 and 3 the selected links will be opened as a new tab in a left-to-right order at the left side of the tab with id=1 in the background. Formerly opened tabs get pushed to the right. The tab order should be: [testcase][id=2][id=3][id=1]
(firefox-bin:6322): GLib-WARNING **: g_set_prgname() called multiple times
ERROR - Test Failure: {u'exception': {u'message': u'could not validate element ID: id with text 2', u'lineNumber': 656, u'stack': u'Error("could not validate element ID: id with text 2")@:0\n([object Object],2)@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/controller.js:656\n()@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js -> file:///etc/mercurial/mozmill/mozmill-tests/firefox/testTabbedBrowsing/testOpenInBackground.js:106\n((function () {PrefsAPI.preferencesDialog.open(prefDialogCallback);controller.open(localTestFolder + "openinnewtab.html");controller.waitForPageLoad();for (var i = 0; i < gTabOrder.length; i++) {var currentLink = new (elementslib.Name)(controller.tabs.activeTab, "link_" + (i + 1));var contextMenuItem = new (elementslib.ID)(controller.window.document, "context-openlinkintab");if (i == 2) {controller.middleClick(currentLink);} else {controller.rightClick(currentLink);controller.click(contextMenuItem);UtilsAPI.closeContentAreaContextMenu(controller);}controller.waitForEval("subject.length == " + (i + 2), gTimeout, 100, tabBrowser);controller.waitForEval("subject.selectedIndex == 0", gTimeout, 100, tabBrowser);if (i == 0) {tabBrowser.selectedIndex = 1;tabBrowser.selectedIndex = 0;}}for each (tab in gTabOrder) {var linkId = new (elementslib.ID)(controller.tabs.getTab(tab.index), "id");controller.waitForElement(linkId);controller.assertText(linkId, tab.linkid);}tabBrowser.selectedIndex = 3;tabBrowser.closeTab({type: "closeButton"});controller.waitForEval("subject.length == 3", gTimeout, 100, tabBrowser);controller.waitForEval("subject.selectedIndex == 2", gTimeout, 100, tabBrowser);}))@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js:468\n([object Object])@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js:520\n([object Object])@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js:562\n("/etc/mercurial/mozmill/mozmill-tests/firefox/testTabbedBrowsing/testOpenInBackground.js")@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js:420\n("/etc/mercurial/mozmill/mozmill-tests/firefox/testTabbedBrowsing/testOpenInBackground.js")@file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/frame.js:574\n((function (filename, invokedFromIDE) {var runner = new Runner(new Collector, invokedFromIDE);runner.runTestFile(filename);runner.end();return true;}),[object Array])@file:///tmp/tmp0dq9ef.mozrunner/extensions/jsbridge@mozilla.com/resource/modules/server.js:164\n("ce859108-30a6-11df-a337-0013ce8d5683",(function (filename, invokedFromIDE) {var runner = new Runner(new Collector, invokedFromIDE);runner.runTestFile(filename);runner.end();return true;}),[object Array])@file:///tmp/tmp0dq9ef.mozrunner/extensions/jsbridge@mozilla.com/resource/modules/server.js:168\n@file:///tmp/tmp0dq9ef.mozrunner/extensions/jsbridge@mozilla.com/resource/modules/server.js:244\n', u'fileName': u'file:///tmp/tmp0dq9ef.mozrunner/extensions/mozmill@mozilla.com/resource/modules/controller.js'}}
Test Failed : testOpenInBackgroundTab in /etc/mercurial/mozmill/mozmill-tests/firefox/testTabbedBrowsing/testOpenInBackground.js
Passed 2 :: Failed 1 :: Skipped 0
Assignee | ||
Comment 1•15 years ago
|
||
Please make sure you really run tests with the above given version of Firefox. Please run Mozmill from the command line without specifying a test folder and check which version has been started. Looks like you are running your tests with Firefox 3.5.x against the default branch of the mozmill-tests repository.
Works fine for me:
$ mozmill -b /Applications/Namoroka.app/ -t firefox/testTabbedBrowsing/testOpenInBackground.js
Passed 3 :: Failed 0 :: Skipped 0
Summary: Automated Test:Open a link in a new tab that opens in the background; Litmus #8087 → [mozmill] Open a link in a new tab that opens in the background
Assignee | ||
Updated•15 years ago
|
Summary: [mozmill] Open a link in a new tab that opens in the background → [mozmill] Failure in testOpenInBackground.js when run in Firefox 3.6.x
Reporter | ||
Comment 2•15 years ago
|
||
Removed some lines of code from the original test script to narrow down the failure.
Assignee | ||
Comment 3•15 years ago
|
||
I got the same failure notice today while running release tests against 3.6.2:
http://brasstacks.mozilla.com/couchdb/mozmill/_design/reports/_show/report/d759a17e312e11dfa6f6005056a533eb
Lets see if I can reproduce it on that box. And it looks like that testOpenInForeground.js is also affected.
Assignee | ||
Comment 4•15 years ago
|
||
Looks like this is a Linux only issue. As reason are the rounded borders or the padding. We click on 0/0 which is outside of the boundary of the tab. I will come up with a patch.
Assignee | ||
Comment 5•15 years ago
|
||
With this patch we click the tab not at the position (0/0) but on (2/2). This solves the issue. I wonder why it happens now and hasn't been seen earlier.
Mark, can you also test if this fixes the problem for you?
Attachment #432952 -
Flags: review?(anthony.s.hughes)
Comment on attachment 432952 [details] [diff] [review]
Patch v1 [checked-in]
r+
This has got me thinking. Is there any reason we can just get the dimensions of the element and divide by 2? This would allow us to dynamically generate the center coordinates of any element and click there. If we did this within the click() method in the API, test coders would not have to pass in any additional parameters than the element.
Attachment #432952 -
Flags: review?(anthony.s.hughes) → review+
Reporter | ||
Comment 7•15 years ago
|
||
Henrik, I added the line this._controller.click(this.getTab(index), 2, 2);
to shared-modules/testTabbedBrowsingAPI.js and that fixed it.I ran testOpenInBackground.js separately and with the entire test suite, and it passed both times.
Assignee | ||
Comment 8•15 years ago
|
||
Thanks for testing it Mark! So lets push this as an interim fix until bug 552846 has been fixed. We should revert it by then. I'll leave this bug open.
Fix landed as:
http://hg.mozilla.org/qa/mozmill-tests/rev/27eb44884e3e
http://hg.mozilla.org/qa/mozmill-tests/rev/9d9cefcb30e1
Depends on: 552846
Assignee | ||
Updated•15 years ago
|
Whiteboard: [mozmill-test-failure]
Assignee | ||
Comment 9•15 years ago
|
||
Mmh, this failure now also appears on OS X. See:
http://brasstacks.mozilla.com/couchdb/mozmill/_design/reports/_show/report/dbacaaae375b11df8778005056a533eb
OS: Linux → All
Hardware: x86 → All
Assignee | ||
Updated•15 years ago
|
Assignee: hskupin → nobody
Status: ASSIGNED → NEW
Comment 10•15 years ago
|
||
Is this test-failure still being worked on?
I was investing this test failure and it's due to some random occurrence where a
new tab (about:blank) is opened up alongside the last tab similar to what I am seeing in bug 573582
Assignee | ||
Comment 11•15 years ago
|
||
You can take it Aaron. I haven't time to do further work here. So please feel free to assign the bug to yourself.
Comment 12•15 years ago
|
||
This fix addresses the timeout that occurs when during a test-run on some runs, a secondary tab is opened (about:blank) on the right click of the context menu, followed by a click to open the corresponding link in a new tab, see [1]. In this case adding a sleep() prevents this occurrence from happening.
[1] http://brasstacks.mozilla.com/couchdb/mozmill/_design/reports/_show/report/63a483947eda11dfbd2f005056a533eb
Assignee: nobody → aaron.train
Status: NEW → ASSIGNED
Attachment #453570 -
Flags: superreview?(hskupin)
Attachment #453570 -
Flags: review?(anthony.s.hughes)
Comment 13•15 years ago
|
||
Typo in controller
Attachment #453570 -
Attachment is obsolete: true
Attachment #453572 -
Flags: superreview?(hskupin)
Attachment #453572 -
Flags: review?(anthony.s.hughes)
Attachment #453570 -
Flags: superreview?(hskupin)
Attachment #453570 -
Flags: review?(anthony.s.hughes)
Assignee | ||
Comment 14•15 years ago
|
||
Comment on attachment 453572 [details] [diff] [review]
v1.1 patch
Please only ask for sr once you got your patch r+'ed.
Attachment #453572 -
Flags: superreview?(hskupin)
Comment 15•15 years ago
|
||
(In reply to comment #14)
> (From update of attachment 453572 [details] [diff] [review])
> Please only ask for sr once you got your patch r+'ed.
In fact, just ask for review. If the reviewer r+ and thinks it needs further review, they will nominate it for you.
Comment 16•15 years ago
|
||
(In reply to comment #12)
> Created an attachment (id=453570) [details]
> v1.0 patch
>
> This fix addresses the timeout that occurs when during a test-run on some runs,
> a secondary tab is opened (about:blank) on the right click of the context menu,
> followed by a click to open the corresponding link in a new tab, see [1]. In
> this case adding a sleep() prevents this occurrence from happening.
>
Over recent days, I've be come far more in favour of using waitForEval() instead of sleep(). It there some property we can check on timeout instead of using a sleep? Aaron, please investigate and comment here. I'll hold off my review until you get back to me.
Thanks.
Comment 17•15 years ago
|
||
Thanks for the continuing feedback. Doesn't hurt to ask if you have ever seen cases where clicking on a link opens an extra tab?
Comment 18•15 years ago
|
||
(In reply to comment #17)
> Thanks for the continuing feedback. Doesn't hurt to ask if you have ever seen
> cases where clicking on a link opens an extra tab?
hyperlinks have a TARGET attribute. If target="_blank" it will open in a new tab via left click.
Assignee | ||
Comment 19•15 years ago
|
||
May I ask which tabs are open in such a situation? Do you have a list of those? The testcase file we are using shouldn't create more tabs as we want to open. Could that be the same failure as which we can see for testOpenInForeground sometimes?
Comment 20•15 years ago
|
||
(In reply to comment #18)
> (In reply to comment #17)
> > Thanks for the continuing feedback. Doesn't hurt to ask if you have ever seen
> > cases where clicking on a link opens an extra tab?
>
> hyperlinks have a TARGET attribute. If target="_blank" it will open in a new
> tab via left click.
I'm talking about an _extra_ tab opening alongside the targeted tab. I click a link, and two tabs open (my target) and a blank.
Comment 21•15 years ago
|
||
(In reply to comment #19)
> May I ask which tabs are open in such a situation? Do you have a list of those?
> The testcase file we are using shouldn't create more tabs as we want to open.
> Could that be the same failure as which we can see for testOpenInForeground
> sometimes?
If the failure on that test is on an assert for a tab count because an extra tab is spawned, than it is most likely related.
Comment 22•15 years ago
|
||
> I'm talking about an _extra_ tab opening alongside the targeted tab. I click a
> link, and two tabs open (my target) and a blank.
If you can narrow down what reproduces this in Mozmill, we can try to use that to reproduce manually. If we can reproduce manually, that means we've uncovered a Firefox bug. It may be worth investigating...
Comment 23•15 years ago
|
||
Narrowed this down to switching tabs rapidly in http://hg.mozilla.org/qa/mozmill-tests/file/ea762f97fd0b/firefox/testTabbedBrowsing/testOpenInBackground.js#l102
Currently on trunk, tab animation was recently introduced which is not as instantaneous in tab creation. I think we're trying to switch to a tab which hasn't fully opened. Presently no preference to disable this in order to test until the patch in bug 380960 lands
Updated•15 years ago
|
Attachment #453572 -
Attachment is obsolete: true
Attachment #453572 -
Flags: review?(anthony.s.hughes)
Comment 24•15 years ago
|
||
> Currently on trunk, tab animation was recently introduced which is not as
> instantaneous in tab creation. I think we're trying to switch to a tab which
> hasn't fully opened.
Shouldn't be a problem. Tab creation should be instantaneous, except that a new tab won't immediately have the full width.
Comment 25•15 years ago
|
||
Hmm because I can simulate a non-test failure with a sleep just before we change tabs
Assignee | ||
Comment 26•15 years ago
|
||
Aaron, can you create a really simplified Mozmill test I can use to reproduce this issue? And it can't really be related to the animation because we also have those failures on 1.9.2 and 1.9.1.
Comment 27•15 years ago
|
||
Henrik, I am speaking about this test failure
http://brasstacks.mozilla.com/couchdb/mozmill/_design/reports/_show/report/1b666dba7fa511dfb4d6005056a533eb
See testcase, give it a few runs and it fails.
Comment 28•15 years ago
|
||
Anyways, the most appropriate and working solution is to just wait until the tab in the background has completed by checking it's single element, i.e., waitForElement
Attachment #454167 -
Flags: review?(anthony.s.hughes)
Assignee | ||
Comment 29•15 years ago
|
||
Comment on attachment 454167 [details] [diff] [review]
v1.1 patch
>+ // Wait for the tab to load in the background before proceeding
>+ var lastIndex = controller.tabs.length - 1;
>+ controller.waitForElement(new elementslib.ID(controller.tabs.getTab(lastIndex), "id"));
>+
This is wrong because we can't always check the last tab. Instead move the waitForPageLoad call from line 108 into the last for each loop. That should be everything we need. Same applies to bug 557799.
Sorry for stealing the review request but Geo has discovered a similar thing for another test on the default branch.
Attachment #454167 -
Flags: review?(anthony.s.hughes) → review-
Comment 30•15 years ago
|
||
(In reply to comment #29)
> (From update of attachment 454167 [details] [diff] [review])
> >+ // Wait for the tab to load in the background before proceeding
> >+ var lastIndex = controller.tabs.length - 1;
> >+ controller.waitForElement(new elementslib.ID(controller.tabs.getTab(lastIndex), "id"));
> >+
>
> This is wrong because we can't always check the last tab. Instead move the
> waitForPageLoad call from line 108 into the last for each loop. That should be
> everything we need. Same applies to bug 557799.
>
> Sorry for stealing the review request but Geo has discovered a similar thing
> for another test on the default branch.
Not seeing a waitForPageLoad call on line 108
Assignee | ||
Comment 31•15 years ago
|
||
I was looking at the 1.9.1 branch. Seems like our tests differ here.
Doing a general check for the id in the second loop should be preceded by a waitForPageLoad for the given index. If we have a problem with switching tabs in the first loop (i==0) then another single waitForPageLoad should be inserted there.
Comment 32•15 years ago
|
||
(In reply to comment #31)
> I was looking at the 1.9.1 branch. Seems like our tests differ here.
>
> Doing a general check for the id in the second loop should be preceded by a
> waitForPageLoad for the given index. If we have a problem with switching tabs
> in the first loop (i==0) then another single waitForPageLoad should be inserted
> there.
I had that check because the test failure is on the waitForEval prior to the id check.
Assignee | ||
Comment 33•15 years ago
|
||
Ok, seems like I missed a bit of the history on that bug. Given your comment 23 a fix for selecting different tabs too quickly should help here. A waitForElement for the id element between the selectedIndex assignments in the i==0 case seems to be the right way. Can you confirm that?
Comment 34•15 years ago
|
||
(In reply to comment #33)
> Ok, seems like I missed a bit of the history on that bug. Given your comment 23
> a fix for selecting different tabs too quickly should help here. A
> waitForElement for the id element between the selectedIndex assignments in the
> i==0 case seems to be the right way. Can you confirm that?
Well kind of. The check, i.e., needs to be prior to tabBrowser.selectedIndex = 1, otherwise it will timeout as their is an extra tab (about:blank) opened as the selected index.
Assignee | ||
Comment 35•15 years ago
|
||
(In reply to comment #34)
> Well kind of. The check, i.e., needs to be prior to tabBrowser.selectedIndex =
> 1, otherwise it will timeout as their is an extra tab (about:blank) opened as
> the selected index.
Well that could mean that we click on the "New Tab" button:
http://hg.mozilla.org/qa/mozmill-tests/file/e34cdbefea63/shared-modules/testTabbedBrowsingAPI.js#l118
Can you please check what "this.getTab(index)" returns in that case? If we have a valid element please check its properties. If it's not a tab we have a failure in our API.
Comment 36•15 years ago
|
||
(In reply to comment #35)
> (In reply to comment #34)
> > Well kind of. The check, i.e., needs to be prior to tabBrowser.selectedIndex =
> > 1, otherwise it will timeout as their is an extra tab (about:blank) opened as
> > the selected index.
>
> Well that could mean that we click on the "New Tab" button:
> http://hg.mozilla.org/qa/mozmill-tests/file/e34cdbefea63/shared-modules/testTabbedBrowsingAPI.js#l118
>
> Can you please check what "this.getTab(index)" returns in that case? If we have
> a valid element please check its properties. If it's not a tab we have a
> failure in our API.
this.getTab(index) is returning tabbrowser-tab objects.
Assignee | ||
Comment 37•15 years ago
|
||
(In reply to comment #24)
> Shouldn't be a problem. Tab creation should be instantaneous, except that a new
> tab won't immediately have the full width.
And that's the problem here. We are synthesizing mouse clicks at a position on the tabs toolbar which will be covered by the tab after it has been faded in. But when we fire the synthesizeMouse event immediately it get passed to the new tab button and a new tab is created. Dao, is there any property or attribute we can wait for to make it reliable?
Aaron, this bug was initially created for 1.9.2 and 1.9.1 work. Now it has been turned into a default branch issue. Beside the fade-in problem please investigate the failures for Firefox 3.6 and 3.5. Thanks.
Comment 38•15 years ago
|
||
(In reply to comment #37)
> (In reply to comment #24)
> > Shouldn't be a problem. Tab creation should be instantaneous, except that a new
> > tab won't immediately have the full width.
>
> And that's the problem here. We are synthesizing mouse clicks at a position on
> the tabs toolbar which will be covered by the tab after it has been faded in.
> But when we fire the synthesizeMouse event immediately it get passed to the new
> tab button and a new tab is created. Dao, is there any property or attribute we
> can wait for to make it reliable?
>
> Aaron, this bug was initially created for 1.9.2 and 1.9.1 work. Now it has been
> turned into a default branch issue. Beside the fade-in problem please
> investigate the failures for Firefox 3.6 and 3.5. Thanks.
There's still failures in this test on 1.9.1 and 1.9.2:
http://brasstacks.mozilla.com/couchdb/mozmill/_design/reports/_show/report/32650734839111df9a2b005056a533eb
http://brasstacks.mozilla.com/couchdb/mozmill/_design/reports/_show/report/b2da6c54839311dfb1d1005056a533eb
Comment 39•15 years ago
|
||
Henrik mentioned that we will have to make a change in our tabs API to listen for 'transitionend', i.e., see bug 578373
Comment 40•15 years ago
|
||
After we right click and middle click to load local content, if I set a waitForPageLoad:
controller.waitForPageLoad(controller.tabs.getTab(i), 100, 100);
This seems to do the trick, any higher regular Timeout internal, i.e., 5 seconds and the test will hang on the five seconds because the local content is loaded quickly. Henrik, is 100 ok for this?
Comment 41•15 years ago
|
||
This is because we are are loading tabs in the background, I need to wait for the local-content tab to finish loading in the background.
Comment 42•15 years ago
|
||
nm this will fail after 30 seconds if timeout isnt met
I'm out of ideas on how to wait for background tabs to finish loading local content
Comment 43•15 years ago
|
||
(In reply to comment #42)
> nm this will fail after 30 seconds if timeout isnt met
>
> I'm out of ideas on how to wait for background tabs to finish loading local
> content
I should say, aside from setting a timeout value to around ~500.
Assignee | ||
Comment 44•15 years ago
|
||
(In reply to comment #40)
> After we right click and middle click to load local content, if I set a
> waitForPageLoad:
> controller.waitForPageLoad(controller.tabs.getTab(i), 100, 100);
>
> This seems to do the trick, any higher regular Timeout internal, i.e., 5
> seconds and the test will hang on the five seconds because the local content is
> loaded quickly. Henrik, is 100 ok for this?
Do you say that waitForPageLoad doesn't catch loading the page when you set a higher timeout? Btw. 2 parameters should be enough, the tab and the timeout.
Comment 45•15 years ago
|
||
(In reply to comment #44)
> (In reply to comment #40)
> > After we right click and middle click to load local content, if I set a
> > waitForPageLoad:
> > controller.waitForPageLoad(controller.tabs.getTab(i), 100, 100);
> >
> > This seems to do the trick, any higher regular Timeout internal, i.e., 5
> > seconds and the test will hang on the five seconds because the local content is
> > loaded quickly. Henrik, is 100 ok for this?
>
> Do you say that waitForPageLoad doesn't catch loading the page when you set a
> higher timeout? Btw. 2 parameters should be enough, the tab and the timeout.
If I use the test default 5 seconds, the test will pause for 5 seconds right after I open the tab. If I remove the parameters the same behaviour applies, but a delay of about ~30 seconds (default).
Assignee | ||
Comment 46•15 years ago
|
||
So this failure is really suspicious. I did some debug logging and run a loop for about 100 times. We always fail at some point. It can be in the 12th iteration or 67th one. In the case below we fail in loop 60:
* Loop: 59
** Element: [object XPCNativeWrapper [object HTMLSpanElement]]
** Expected: 2 Current: 2
** Element: [object XPCNativeWrapper [object HTMLSpanElement]]
** Expected: 3 Current: 3
** Element: [object XPCNativeWrapper [object HTMLSpanElement]]
** Expected: 1 Current: 1
* Loop: 60
** Element: [object XPCNativeWrapper [object HTMLSpanElement]]
** Expected: 2 Current:
As you can see the span element exists but the innerHTML property is empty. It can only happen when we don't supply an id to the currently loaded URL.
Assignee | ||
Comment 47•15 years ago
|
||
Sorry, this is totally my fault. We have a race condition here in our test file. The span element shouldn't exist from the beginning on but should be inserted into the DOM. I will come up with a patch for it. Lemme steal this bug again.
Assignee: aaron.train → hskupin
Assignee | ||
Updated•15 years ago
|
Attachment #432952 -
Attachment description: Patch v1 → Patch v1 [checked-in]
Assignee | ||
Updated•15 years ago
|
Attachment #454044 -
Attachment is obsolete: true
Assignee | ||
Comment 48•15 years ago
|
||
Ok, so the reason is that the span element with the id exists all the time. So waitForElement will return immediately. But under some conditions the script block in the local test file gets executed lazily. That means we have an empty span element and can't assert with the real id.
Aaron, this patch is a debug patch. Please test it on mozilla1.9.2 if it fixes the problems for you too. I will then create a real patch.
Attachment #432951 -
Attachment is obsolete: true
Attachment #454167 -
Attachment is obsolete: true
Attachment #459239 -
Flags: feedback?(aaron.train)
Comment 49•15 years ago
|
||
Comment on attachment 459239 [details] [diff] [review]
Possible fix
Ran this debug patch through multiple runs each producing expected output and passes. Thanks Henrik for helping expedite the investigation in this.
Attachment #459239 -
Flags: feedback?(aaron.train) → feedback+
Assignee | ||
Comment 50•15 years ago
|
||
Aaron, thanks for testing. Can you please run some complete test-runs with this patch applied on all branches and when possible on different platforms. As we know we can fail in some cases on default due to the tab opening animation. I will take care of it in the other bug.
Attachment #459239 -
Attachment is obsolete: true
Attachment #459399 -
Flags: review?(aaron.train)
Comment 51•15 years ago
|
||
Ran this patch across all branches and all three platforms this morning and am not receiving test fails as related to this particular bug but am receiving a new persistent fail in all branches:
Test Failed : testScrollBackgroundTabIntoView in /firefox/testTabbedBrowsing/testBackgroundTabScrolling.js
ERROR - Test Failure: {u'exception': {u'message': u'Controller.assertJS("subject.childNodes[9].label == \'2\'")', u'lineNumber': 726, u'stack': u'Error("Controller.assertJS(\\"subject.childNodes[9].label == \'2\'\\")")@:0\n("subject.childNodes[9].label == \'2\'",[object XULElement])@file:/testBackgroundTabScrolling.js:122
Assignee | ||
Comment 52•15 years ago
|
||
(In reply to comment #51)
> new persistent fail in all branches:
>
> ERROR - Test Failure: {u'exception': {u'message':
> u'Controller.assertJS("subject.childNodes[9].label == \'2\'")', u'lineNumber':
Which makes sense. Forgot to qrefresh the patch before attaching the patch to that bug. This version should again display only the id in the document and tab title.
Attachment #459399 -
Attachment is obsolete: true
Attachment #459429 -
Flags: review?(aaron.train)
Attachment #459399 -
Flags: review?(aaron.train)
Comment 53•15 years ago
|
||
Comment on attachment 459429 [details] [diff] [review]
Patch v2 for test file
Fixed issue previously mentioned and passes all tab tests.
Attachment #459429 -
Flags: review?(aaron.train) → review+
Assignee | ||
Comment 54•15 years ago
|
||
Landed on all branches as:
http://hg.mozilla.org/qa/mozmill-tests/rev/04fecdc66faa
http://hg.mozilla.org/qa/mozmill-tests/rev/2d7bb1b96cdc
http://hg.mozilla.org/qa/mozmill-tests/rev/32dec3f817b5
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 55•15 years ago
|
||
Also updated the litmus-data test:
http://hg.mozilla.org/qa/litmus-data/rev/3b5841159d2b
Assignee | ||
Comment 56•14 years ago
|
||
Mass move of Mozmill Test related project bugs to newly created components. You can filter out those emails by using "Mozmill-Tests-to-MozillaQA" as criteria.
Component: Tabbed Browser → Mozmill Tests
Product: Firefox → Mozilla QA
QA Contact: tabbed.browser → mozmill-tests
Updated•6 years ago
|
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•