Closed
Bug 760374
Opened 12 years ago
Closed 12 years ago
testBlueLarry fails with Disconnect error
Categories
(Mozilla QA Graveyard :: Mozmill Tests, defect)
Mozilla QA Graveyard
Mozmill Tests
Tracking
(firefox14 fixed, firefox15 verified, firefox16 fixed, firefox17 fixed, firefox-esr10 verified)
People
(Reporter: u279076, Assigned: vladmaniac)
References
()
Details
(Whiteboard: [mozmill-test-failure])
Attachments
(2 files, 8 obsolete files)
3.88 KB,
patch
|
whimboo
:
review+
|
Details | Diff | Splinter Review |
4.79 KB,
patch
|
whimboo
:
review+
|
Details | Diff | Splinter Review |
Running the ondemand scripts today for the 10.0.5esr builds, testBlueLarry.js reported a Disconnect error twice. Once on Windows 7 and again on Windows XP: http://mozmill-ondemand.blargon7.com/#/functional/report/fdec829b93b19c73985be1d38840c448 http://mozmill-ondemand.blargon7.com/#/functional/report/fdec829b93b19c73985be1d38840e1d3
Assignee | ||
Comment 1•12 years ago
|
||
This is also for mac http://mozmill-ondemand.blargon7.com/#/functional/report/fdec829b93b19c73985be1d38841629c
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → vlad.mozbugs
Status: NEW → ASSIGNED
Comment 2•12 years ago
|
||
Vlad will take care of it. Just checked quickly and it started to happen on May 25th. Could be a Firefox regression?
Updated•12 years ago
|
status-firefox-esr10:
--- → affected
status-firefox12:
--- → unaffected
status-firefox13:
--- → unaffected
status-firefox14:
--- → unaffected
status-firefox15:
--- → unaffected
Summary: [esr] testBlueLarry fails with Disconnect error → testBlueLarry fails with Disconnect error
Updated•12 years ago
|
Severity: normal → major
Assignee | ||
Comment 3•12 years ago
|
||
I cannot trigger this disconnect locally http://mozmill-crowd.blargon7.com/#/functional/reports?branch=All&platform=All&from=2012-06-01&to=2012-06-01 are we sure this is not system dependent? If time permits, I would suggest someone to start a testrun on the exact machine we are seeing this. I the meantime, I will do a hg bisect to see if we have some changes in the Security UI
Severity: major → normal
status-firefox-esr10:
affected → ---
status-firefox12:
unaffected → ---
status-firefox13:
unaffected → ---
status-firefox14:
unaffected → ---
status-firefox15:
unaffected → ---
Assignee | ||
Updated•12 years ago
|
Severity: normal → major
status-firefox-esr10:
--- → affected
status-firefox12:
--- → unaffected
status-firefox13:
--- → unaffected
status-firefox14:
--- → unaffected
status-firefox15:
--- → unaffected
Assignee | ||
Comment 4•12 years ago
|
||
Don't see any changes related to Security UI in http://hg.mozilla.org/releases/mozilla-esr10/pushloghtml?fromchangeset=282ed6ece1f6&tochangeset=5713c92407dd So is it remote environment dependent? My mac mini is still running tests and reporting to mozmill-crowd. Hope we catch something
Assignee | ||
Comment 5•12 years ago
|
||
Have lots of local reports for this but no error. Also I see nothing of this on mozmill-release in the last 5 days This occurred only on Mac OS X 10.6.8 four times in one month http://mozmill-release.blargon7.com/#/functional/failure?branch=10.0&platform=Mac&from=2012-05-06&to=2012-06-05&test=%2FtestSecurity%2FtestBlueLarry.js&func=testLarryBlue
Comment 6•12 years ago
|
||
Given that it happens that rarely lets close this bug for now. Once it manifests again we should check the failure on the same day. Could be that there were some issues with external sites or whatever.
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Comment 7•12 years ago
|
||
This happened yesterday with an ESR10 build: http://mozmill-ci.blargon7.com/#/functional/report/ee284dfa9d664754a65676abbc1300df Could someone please try if it is reproducible?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Comment 8•12 years ago
|
||
Managed to reproduce it with low memory in a Mac. Before starting Firefox, ~150 MB were available in RAM. It failed 2 times out of 30. Disk space is ~25 MB. I cannot reproduce it 100% and it does not leave a Firefox open. I'll try to tun the folder alone.
Comment 9•12 years ago
|
||
Oh, sorry, this were the results for the beta candidate: http://mozmill-crowd.blargon7.com/#/functional/report/e67171ea696231bb192f565615041b76
Comment 10•12 years ago
|
||
Vlad, please transform this test to make use of mozqa.com. There we have a DV cert available. Lets hope that it will make a difference.
Comment 11•12 years ago
|
||
This is critical. So please figure out who can do this change early tomorrow. thanks!
Severity: major → critical
Status: REOPENED → NEW
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•12 years ago
|
||
Modified test to use one of our ssl - dv cert pages from mozqa.com
Attachment #636660 -
Flags: review?(hskupin)
Assignee | ||
Updated•12 years ago
|
Attachment #636660 -
Flags: review?(dave.hunt)
Comment 13•12 years ago
|
||
Comment on attachment 636660 [details] [diff] [review] patch v 1.0 >+const LOCAL_TEST_PAGE = "https://ssl-dv.mozqa.com/data/" + >+ "firefox/layout/mozilla_community.html"; This is not a local test page. Beside that just use the plain domain. >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "ssl-dv")); [..] > controller.assertValue(webIDOwnerLabel, securityOwner); While you are on it please change this to an expect call. Whereby you don't have to do any replacement. This cert is exclusively for this sub domain.
Attachment #636660 -
Flags: review?(hskupin)
Attachment #636660 -
Flags: review?(dave.hunt)
Attachment #636660 -
Flags: review-
Assignee | ||
Comment 14•12 years ago
|
||
>
> While you are on it please change this to an expect call. Whereby you don't
> have to do any replacement. This cert is exclusively for this sub domain.
I still have to do the replacement because webIDDOmainLabel will be the full domain name, and cert.commonName will be '*.mozqa.com'. The expect.equal does not change that. If I understood what you meant there by 'replacement'
Assignee | ||
Comment 15•12 years ago
|
||
r=hskupin this time because its the second iteration
Attachment #636660 -
Attachment is obsolete: true
Attachment #637033 -
Flags: review?(hskupin)
Comment 16•12 years ago
|
||
Comment on attachment 637033 [details] [diff] [review] patch v2.0 >+const TEST_PAGE = "https://ssl-dv.mozqa.com"; In this case I still see no reason why to introduce a global constant. Just leave it as is in the test. >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ expect.equal(webIDDomainLabel.getNode().value, cert.commonName.replace("*", "ssl-dv"), >+ "Web Site label equals '" + cert.commonName + "'"); Please read my review comment correctly. There is no need for a replace. >+ expect.equal(webIDOwnerLabel.getNode().value, securityOwner, >+ "Owner label equals '" + securityOwner + "'"); Putting the variable you already have as 2nd argument in the message doesn't make sense. It's just duplicated. Instead say "Expected owner label found" or similar. >- controller.assertValue(webIDVerifierLabel, cert.issuerOrganization); >+ expect.equal(webIDVerifierLabel.getNode().value, cert.issuerOrganization, >+ "Verifier label equals '" + cert.issuerOrganization + "'"); Same here.
Attachment #637033 -
Flags: review?(hskupin) → review-
Comment 17•12 years ago
|
||
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #14) > I still have to do the replacement because webIDDOmainLabel will be the full > domain name, and cert.commonName will be '*.mozqa.com'. The expect.equal > does not change that. If I understood what you meant there by 'replacement' User expect.match() instead of expect.equal(). But can you show me the logging output for that?
Assignee | ||
Comment 18•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #17) > (In reply to Maniac Vlad Florin (:vladmaniac) from comment #14) > > I still have to do the replacement because webIDDOmainLabel will be the full > > domain name, and cert.commonName will be '*.mozqa.com'. The expect.equal > > does not change that. If I understood what you meant there by 'replacement' > > User expect.match() instead of expect.equal(). But can you show me the > logging output for that? Log: "message": "Web Site label equals '*.mozqa.com' - 'ssl-dv.mozqa.com' should equal '*.mozqa.com'", "lineNumber": 111, "name": "checkSecurityTab", "fileName": "file:///home/vladmaniac/Desktop/testBlueLarry/mozmill-tests/tests/functional/testSecurity/testBlueLarry.js"}}], "name": "testBlueLarry.js::testLarryBlue", "filename": "/home/vladmaniac/Desktop/testBlueLarry/mozmill-tests/tests/functional/testSecurity/testBlueLarry.js", "failed": 1, "passed": 18} expect line causing the log: expect.equal(webIDDomainLabel.getNode().value, cert.commonName, "Web Site label equals '" + cert.commonName + "'");
Comment 19•12 years ago
|
||
When I open the cert panel I see: "ssl-dv.mozqa.com" as label. Where does '*.mozqa.com' come from? Also we should change the testname because we no longer show a blue larry. A name like testDVCert.js would be more appropriate.
Assignee | ||
Comment 20•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #19) > When I open the cert panel I see: "ssl-dv.mozqa.com" as label. Where does > '*.mozqa.com' come from? cert.commonName has that value > > Also we should change the testname because we no longer show a blue larry. A > name like testDVCert.js would be more appropriate. This won't be a problem
Comment 21•12 years ago
|
||
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #20) > (In reply to Henrik Skupin (:whimboo) from comment #19) > > When I open the cert panel I see: "ssl-dv.mozqa.com" as label. Where does > > '*.mozqa.com' come from? > > cert.commonName has that value This can't be given your expect.equal() line you have pointed out above. There this variable is on the 2nd position and correlates to 'ssl-dv.mozqa.com'.
Assignee | ||
Comment 22•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #21) > (In reply to Maniac Vlad Florin (:vladmaniac) from comment #20) > > (In reply to Henrik Skupin (:whimboo) from comment #19) > > > When I open the cert panel I see: "ssl-dv.mozqa.com" as label. Where does > > > '*.mozqa.com' come from? > > > > cert.commonName has that value > > This can't be given your expect.equal() line you have pointed out above. > There this variable is on the 2nd position and correlates to > 'ssl-dv.mozqa.com'. Please add dump("\n\n webID = " + webIDDomainLabel.getNode().value + "\n\n"); dump("\n\n cert.commonName = " + cert.commonName + "\n\n"); Thanks what I did before answering comment 20
Assignee | ||
Comment 23•12 years ago
|
||
fixed with expect.match and expect.equal no modifications required in strings
Attachment #637033 -
Attachment is obsolete: true
Attachment #637119 -
Flags: review?(hskupin)
Comment 24•12 years ago
|
||
Ok my fault. It's not enough to check the page info window but you really have to check the 'view certificate' window. So yeah, use the cert commonName as a regex for the match() method. You will probably have to escape it first to be a regex.
Assignee | ||
Comment 25•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #24) > Ok my fault. It's not enough to check the page info window but you really > have to check the 'view certificate' window. So yeah, use the cert > commonName as a regex for the match() method. You will probably have to > escape it first to be a regex. So my current patch would be wrong, right?
Comment 26•12 years ago
|
||
Comment on attachment 637119 [details] [diff] [review] patch v3.0 >+++ b/tests/functional/testSecurity/testBlueLarry.js As last step please do not forget to rename the file. Lets do it once the expect call works. >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ expect.match(webIDDomainLabel.getNode().value, cert.commonName, >+ "Expected web site label found"); The regex isn't correct. As mentioned before it has to be escaped first.
Attachment #637119 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 27•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #26) > Comment on attachment 637119 [details] [diff] [review] > patch v3.0 > > >+++ b/tests/functional/testSecurity/testBlueLarry.js > > As last step please do not forget to rename the file. Lets do it once the > expect call works. > > >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); > >+ expect.match(webIDDomainLabel.getNode().value, cert.commonName, > >+ "Expected web site label found"); > > The regex isn't correct. As mentioned before it has to be escaped first. You're right, on it
Assignee | ||
Comment 28•12 years ago
|
||
renamed the file and escaped the string
Attachment #637119 -
Attachment is obsolete: true
Attachment #637162 -
Flags: review?(hskupin)
Comment 29•12 years ago
|
||
Comment on attachment 637162 [details] [diff] [review] patch v4.0 >rename to tests/functional/testSecurity/testDVCert.js Please use testDVCertificate.js. >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ expect.match(webIDDomainLabel.getNode().value, escape(cert.commonName), >+ "Expected web site label found"); This is not the escape method you want for a regex. Please run with --show-all and check the message for this assertion. Also please make a negative test before submitting the next version of the patch.
Attachment #637162 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 30•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #29) > Comment on attachment 637162 [details] [diff] [review] > patch v4.0 > > >rename to tests/functional/testSecurity/testDVCert.js > > Please use testDVCertificate.js. Not a problem > > >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); > >+ expect.match(webIDDomainLabel.getNode().value, escape(cert.commonName), > >+ "Expected web site label found"); > > This is not the escape method you want for a regex. Please run with > --show-all and check the message for this assertion. Also please make a > negative test before submitting the next version of the patch. I am trying to use string.replace, and escape the '*' and '.' characters expect.match(webIDDomainLabel.getNode().value, cert.commonName.replace("*.", "\\*\\."), "Expected web site label found"); I am afraid the output of this line in the console is not the one we want: "message": "Expected web site label found - '/(?:)/' matches for 'ssl-dv.mozqa.com'", "lineNumber": 110, but if I do a simple dump in the console, cert.commonName.replace("*.", "\\*\\.") will echo \*\.mozqa.com which is the output we want What am I doing wrong? Is there some other method you have in mind Henrik?
Comment 31•12 years ago
|
||
I would say use some hardcoded strings to check the match() method first. Once that works we know which regex we have to use.
Assignee | ||
Comment 32•12 years ago
|
||
Right So a passing testcases with match is expect.match("12233344454323", /12233344454323/); and a failing one is expect.match("abcdef", /12233344454323/);
Assignee | ||
Comment 33•12 years ago
|
||
The following line, back in our case expect.match(webIDDomainLabel.getNode().value, /.mozqa.com/, "Expected web site label found"); will echo the following log with --show-all "message": "Expected web site label found - '/.mozqa.com/' matches for 'ssl-dv.mozqa.com'", "lineNumber": 110 I think we are alright now - Henrik?
Comment 34•12 years ago
|
||
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #33) > "message": "Expected web site label found - '/.mozqa.com/' matches for > 'ssl-dv.mozqa.com'", "lineNumber": 110 > > I think we are alright now - Henrik? This will also match: * whatevermozqa.com * amozqaacom.de * sub.mozqa.com.whatever.fqdn.com As pointed out a couple of times, do not forget to do negative tests. We really want to test what the certificat offers.
Assignee | ||
Comment 35•12 years ago
|
||
I was into assertions.js to check 'match' that I forgot a bit our initial purpose ... So we need to separate the exact domain
Assignee | ||
Comment 36•12 years ago
|
||
The regex we want for the mozqa.com subdomain is /^[^\.]*\.mozqa\.com$/ We can easily test this with the web console adding the following /^[^\.]*\.mozqa\.com$/.exec("mozqa.com") echoes null /^[^\.]*\.mozqa\.com$/.exec(".mozqa.com") echoes [15:54:59.837] [".mozqa.com"] /^[^\.]*\.mozqa\.com$/.exec("something.mozqa.com") echoes [15:56:48.041] ["something.mozqa.com"] /^[^\.]*\.mozqa\.com$/.exec("whatevermozqa.com") echoes null /^[^\.]*\.mozqa\.com$/.exec("amozqaacom.de") echoes null /^[^\.]*\.mozqa\.com$/.exec("sub.mozqa.com.whatever.fqdn.com"); echoes null
Assignee | ||
Comment 37•12 years ago
|
||
Henrik or Dave, can you please validate this so that I can upload a fix patch for this test?
Comment 38•12 years ago
|
||
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #36) > The regex we want for the mozqa.com subdomain is > > /^[^\.]*\.mozqa\.com$/ This would not work if you are using multiple subdomains like a.b.c.mozqa.com. The wildcard should IMHO match for all of those.
Assignee | ||
Comment 39•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #38) > (In reply to Maniac Vlad Florin (:vladmaniac) from comment #36) > > The regex we want for the mozqa.com subdomain is > > > > /^[^\.]*\.mozqa\.com$/ > > This would not work if you are using multiple subdomains like > a.b.c.mozqa.com. The wildcard should IMHO match for all of those. I intentionally ruled out that If we want a.b.c.mozqa.com to work the regex is -- [17:17:58.028] /^.*\.mozqa\.com$/.exec("a.b.c.mozqa.com") [17:17:58.070] ["a.b.c.mozqa.com"]
Comment 40•12 years ago
|
||
Right. Now you only have to transform the value from cert.commonName to be '/^.*\.mozqa\.com$/'.
Assignee | ||
Comment 41•12 years ago
|
||
Regex identified and build successfully However if we look into the expect.match log messages we will see an extra "\" added which is abnormal and I will investigate this further most certainly in another bug. I thought so far I was doing things wrong but playing with the expect.match method in the scratchpad everything seems fine so I suspect something in the log method to be not in place. Asking for r from Henrik only since he did it in the last patch
Attachment #637162 -
Attachment is obsolete: true
Attachment #639270 -
Flags: review?(hskupin)
Comment 42•12 years ago
|
||
Comment on attachment 639270 [details] [diff] [review] patch v5.0 >- "security-identity-domain-value"); >+ "security-identity-domain-value"); nit: please remove the trailing blank. >+ var certNameToRegExp = new RegExp("^." + cert.commonName.replace(/\./g, "\\\.") + "$"); That's not enough. You will also have to replace any '*' with '.*'. You shouldn't do this by simply adding the '.' to the prefix string. Also for replace() I would not use a regex but a simple string.
Attachment #639270 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 43•12 years ago
|
||
Also for
> replace() I would not use a regex but a simple string.
I am not successful in using replace() with a simple string due to the fact that we need to replace all the "." with "\." (escaped) so that the RegExp will know that '.' is not a special character. For that I need the regex imo.
Comment 44•12 years ago
|
||
How do you replace? If you have problems please always add the lines of code in the comment. It's not helpful when you lack this information. But ok, seems like you have to use a regex. At least when checking MDN. So just run the replace twice, first for '.' and then for the '*' chars.
Assignee | ||
Comment 45•12 years ago
|
||
All requests addressed
Attachment #639270 -
Attachment is obsolete: true
Attachment #639299 -
Flags: review?(hskupin)
Comment 46•12 years ago
|
||
Comment on attachment 639299 [details] [diff] [review] patch v5.1 >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ var certNameToRegExp = new RegExp("^" + (cert.commonName.replace(/\./g, "\\\.")).replace("*", ".*") + "$"); This line is longer than 80 chars. Please break it into the next line or do it in two separate statements. Also try to find some shorter variable names. Once this is done we are good to land.
Attachment #639299 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 47•12 years ago
|
||
Fixed. Please note that there are many other lines in the test longer than 80 char. Should we split those also? Also the same for the variable names
Attachment #639299 -
Attachment is obsolete: true
Attachment #640521 -
Flags: review?(hskupin)
Comment 48•12 years ago
|
||
Comment on attachment 640521 [details] [diff] [review] patch v5.2 >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ var certName = (cert.commonName.replace(/\./g, "\\\.")).replace("*", ".*"); Sorry, one more thing. Please make both replace calls work on regex. The second one should also be global. >+ var certNameRegExp = new RegExp("^" + certName + "$"); AFAIR you can directly pass in the string too. There shouldn't be the need to create a RegExp instance first. Please try it out.
Attachment #640521 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 49•12 years ago
|
||
All changes addressed. Hope I understood correctly what we want here Also, removed the /XXX comment it seems we missed that. We are no longer doing what the comment said
Attachment #640521 -
Attachment is obsolete: true
Attachment #641468 -
Flags: review?(hskupin)
Comment 50•12 years ago
|
||
Comment on attachment 641468 [details] [diff] [review] patch v5.3 >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); >+ var certName = (cert.commonName.replace(/\./g, "\\\.")).replace(/\*/g, ".*"); When you can replace '*' with a string can we do the same with '.'? I think we should be consistent here. >+ var certName = "^" + certName + "$"; >+ >+ expect.match(webIDDomainLabel.getNode().value, certName, Just do the string concatenation directly in the match() call.
Attachment #641468 -
Flags: review?(hskupin) → review-
Assignee | ||
Comment 51•12 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #50) > Comment on attachment 641468 [details] [diff] [review] > patch v5.3 > > >- controller.assertValue(webIDDomainLabel, cert.commonName.replace("*", "mail")); > >+ var certName = (cert.commonName.replace(/\./g, "\\\.")).replace(/\*/g, ".*"); > > When you can replace '*' with a string can we do the same with '.'? I think > we should be consistent here. > Not sure what you mean here but we replace "." with "\." in the first replace cert.commonName.replace(/\./g, "\\\."), then we replace the "*" with ".*"
Assignee | ||
Comment 52•12 years ago
|
||
> >+ var certNameRegExp = new RegExp("^" + certName + "$");
>
> AFAIR you can directly pass in the string too. There shouldn't be the need
> to create a RegExp instance first. Please try it out.
Also please try this out yourself and look into the match() log message. We need the regex to get the proper log message, instead, we get
Expected web site label found - '/(?:)/' matches for 'ssl-dv.mozqa.com'"
which is not right. So I propose sticking to the regex
Comment 53•12 years ago
|
||
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #52) > > AFAIR you can directly pass in the string too. There shouldn't be the need > > to create a RegExp instance first. Please try it out. > > Also please try this out yourself and look into the match() log message. We > need the regex to get the proper log message, instead, we get > > Expected web site label found - '/(?:)/' matches for 'ssl-dv.mozqa.com'" As I have said you should try this before submitting a new patch for review. Looks like this didn't happen. Also we don't want to try out each individual change in the patch. There should be a trust in writing and fixing testcases, where you as patch author test the correctness. (In reply to Maniac Vlad Florin (:vladmaniac) from comment #51) > Not sure what you mean here but we replace "." with "\." in the first > replace cert.commonName.replace(/\./g, "\\\."), then we replace the "*" with > ".*" Ok, we can leave that. The three backslashes are just an escaped backslash for the special handling of the dot.
Assignee | ||
Comment 54•12 years ago
|
||
fixed
Attachment #641468 -
Attachment is obsolete: true
Attachment #642497 -
Flags: review?(hskupin)
Comment 55•12 years ago
|
||
Comment on attachment 642497 [details] [diff] [review] patch v5.4 Finally it looks good and works. I will land on default now.
Attachment #642497 -
Flags: review?(hskupin) → review+
Comment 56•12 years ago
|
||
Pushed to default: http://hg.mozilla.org/qa/mozmill-tests/rev/c98e20ff0951
Status: ASSIGNED → RESOLVED
Closed: 12 years ago → 12 years ago
status-firefox12:
unaffected → ---
status-firefox16:
--- → fixed
Resolution: --- → FIXED
Comment 57•12 years ago
|
||
Given that we had no new failure today I have landed the patch on the other branches. http://hg.mozilla.org/qa/mozmill-tests/rev/abbd49d6d021 (beta) http://hg.mozilla.org/qa/mozmill-tests/rev/7799f37de1b0 (release) Vlad, please come up with a patch for esr10. Also once it has been landed please update the Litmus test references.
Assignee | ||
Comment 58•12 years ago
|
||
Patch for esr branch
Attachment #642874 -
Flags: review?(hskupin)
Assignee | ||
Comment 59•12 years ago
|
||
Was tested also with the latest candidate build from ftp://ftp.mozilla.org/pub/firefox/nightly/10.0.6esr-candidates/build1/linux-i686/en-US/
Updated•12 years ago
|
Attachment #642874 -
Flags: review?(hskupin) → review+
Comment 60•12 years ago
|
||
Pushed to esr10: http://hg.mozilla.org/qa/mozmill-tests/rev/cbd547036384
Assignee | ||
Comment 61•12 years ago
|
||
Really tried to find all the branches in litmus but it seems to me that we are missing default and beta. Modified for aurora and release branch: release: https://litmus.mozilla.org/show_test.cgi?id=64707 aurora: https://litmus.mozilla.org/show_test.cgi?id=16360 Note: the test was not disabled, its just the mozmill test name changed so updated that info in litmus
Comment 62•12 years ago
|
||
(In reply to Maniac Vlad Florin (:vladmaniac) from comment #61) > Really tried to find all the branches in litmus but it seems to me that we > are missing default and beta. We do not have tests for Nightly in Litmus. And beta is the 14.0 branch. > Modified for aurora and release branch: > release: https://litmus.mozilla.org/show_test.cgi?id=64707 > aurora: https://litmus.mozilla.org/show_test.cgi?id=16360 You should also update the 13.0 branch even it gets obsoleted later today.
Assignee | ||
Comment 63•12 years ago
|
||
Modifications for Firefox 13 were made https://litmus.mozilla.org/show_test.cgi?id=56353
Assignee | ||
Updated•12 years ago
|
Flags: in-litmus?(vlad.mozbugs) → in-litmus+
Comment 64•12 years ago
|
||
The attached patch missed to update the manifest file, so Mozmill 2.0 is broken in running the tests. I had to land this immediately because it's blocking my work for bug 767332: http://hg.mozilla.org/qa/mozmill-tests/rev/bc76dc7bed67 (default) http://hg.mozilla.org/qa/mozmill-tests/rev/1f7a4d048006 (aurora) http://hg.mozilla.org/qa/mozmill-tests/rev/62937f290a30 (beta) http://hg.mozilla.org/qa/mozmill-tests/rev/6bf78d6cd2b7 (release) http://hg.mozilla.org/qa/mozmill-tests/rev/86a076f99fab (esr10)
Comment 65•12 years ago
|
||
The has passed on Firefox 10.0.6 ESR http://mozmill-ondemand.blargon7.com/#/functional/reports?branch=10.0&platform=All&from=2012-07-01&to=2012-08-13 and on Firefox 15.0 beta 4 http://mozmill-ci.blargon7.com/#/functional/reports?branch=15.0&platform=All&from=2012-08-08&to=2012-08-09.
Assignee | ||
Comment 66•12 years ago
|
||
Thanks Ioana!
Updated•5 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
•