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)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: marklocklear, Assigned: whimboo)

References

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(2 files, 8 obsolete files)

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
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
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
Removed some lines of code from the original test script to narrow down the failure.
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.
Blocks: 527983
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file Simplified test (obsolete) —
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: nobody → hskupin
Attachment #432882 - Attachment is obsolete: true
Status: NEW → ASSIGNED
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+
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.
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
Whiteboard: [mozmill-test-failure]
OS: Linux → All
Hardware: x86 → All
Assignee: hskupin → nobody
Status: ASSIGNED → NEW
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
You can take it Aaron. I haven't time to do further work here. So please feel free to assign the bug to yourself.
Attached patch v1.0 patch (obsolete) — Splinter Review
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)
Attached patch v1.1 patch (obsolete) — Splinter Review
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)
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)
(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.
(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.
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?
(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.
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?
(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.
(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.
> 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...
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
Attachment #453572 - Attachment is obsolete: true
Attachment #453572 - Flags: review?(anthony.s.hughes)
> 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.
Hmm because I can simulate a non-test failure with a sleep just before we change tabs
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.
Attached file spawns extra tab testcase (obsolete) —
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.
Attached patch v1.1 patch (obsolete) — Splinter Review
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)
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-
(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
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.
(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.
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?
(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.
(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.
(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.
(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.
(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
Henrik mentioned that we will have to make a change in our tabs API to listen for 'transitionend', i.e., see bug 578373
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?
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.
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
(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.
(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.
(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).
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.
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
Attachment #432952 - Attachment description: Patch v1 → Patch v1 [checked-in]
Attachment #454044 - Attachment is obsolete: true
Attached patch Possible fix (obsolete) — Splinter Review
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)
Blocks: 557799
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+
Attached patch Patch for test file (obsolete) — Splinter Review
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)
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
(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 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+
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
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: