Closed Bug 895996 Opened 10 years ago Closed 8 years ago

[ku] testAddMozSearchProvider.js fails with "Disconnect Error: Application unexpectedly closed" because the print dialog gets opened

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect, P1)

defect

Tracking

(firefox23 wontfix, firefox24 wontfix, firefox25 wontfix, firefox26 fixed, firefox27 unaffected, firefox-esr17 wontfix, firefox-esr24 affected)

RESOLVED FIXED
Tracking Status
firefox23 --- wontfix
firefox24 --- wontfix
firefox25 --- wontfix
firefox26 --- fixed
firefox27 --- unaffected
firefox-esr17 --- wontfix
firefox-esr24 --- affected

People

(Reporter: u279076, Unassigned)

References

Details

(Whiteboard: [mozmill-test-failure])

Attachments

(1 file)

Firefox 23.0 (23.0, ku, 20130718163513) on Windows NT 6.2.9200 (x86_64):
http://mozmill-release.blargon7.com/#/functional/report/180cf2548ef2865af3ae441d611e4314
Mario, can you please run a quick check for the ku locale if it reproduces constantly?
Severity: normal → critical
Flags: needinfo?(mario.garbi)
We can reproduce it locally everytime, the Firefox freezes and is not responding, it might be a regression.

http://mozmill-crowd.blargon7.com/#/functional/report/180cf2548ef2865af3ae441d616498b0
Flags: needinfo?(mario.garbi)
Not sure what you mean with a freeze here. Given that I don't see anything related in the screenshot you gave here. Can you please explain that a bit more? When does it happen? Which version of Windows? Is it native or a VM? Is it specific to the ku locale?
Priority: -- → P1
I was running a VM - Win8 (x86). I am able to reproduce this every run with Ku but not even once with other builds so I am inclined to believe it ku locale specific. By freeze I refer to the firefox process becoming non-responsive as can be seen in the screenshot next to the page title (Not Reponding).

The reports for different locales:
http://mozmill-crowd.blargon7.com/#/functional/reports?branch=23.0&platform=Windows%20NT&from=2013-07-16&to=2013-07-22
Firefox 23.0 (23.0, ku, 20130722172257) - Windows NT 6.0.6002 Service Pack 2 (x86):
> http://mozmill-release.blargon7.com/#/functional/report/180cf2548ef2865af3ae441d61a20b51

Firefox 23.0 (23.0, ku, 20130722172257) - Windows NT 6.2.9200 (x86_64):
> http://mozmill-release.blargon7.com/#/functional/report/180cf2548ef2865af3ae441d61a1ed5d
We have to get this investigated and fixed soonish given that it affects our tests for each beta. Who can work on this?
Assignee: nobody → mario.garbi
I will work on this.
I noticed that we only ran tests from KU with Windows platform so I tested this on Linux and I've noticed that almost all Search tests are failing not just testAddMozSearchProvider due to an incorrect dialogue being opened (Print).
I will check if this is a localization problem or something on our part since we haven't tested KU before.

http://mozmill-crowd.blargon7.com/#/functional/report/180cf2548ef2865af3ae441d61beb1c8
OS: Windows 8 → All
Hardware: x86_64 → All
Might be a locale issue or that we do not use a DTD entity correctly for a shortcut.
Indeed, after going through the code and dtds I found this line that changes Select All shortkey from "a" to "P". This opens in our tests the print dialogue on KU and I suspect this was a mistake on their part.

DTDS:
http://hg.mozilla.org/releases/l10n/mozilla-aurora/ku/rev/baf78810a202#l6.266

Mozmill-tests line that fails:
http://hg.mozilla.org/qa/mozmill-tests/file/963408b08af3/lib/search.js#l576
(In reply to mario garbi from comment #10)
> Indeed, after going through the code and dtds I found this line that changes
> Select All shortkey from "a" to "P". This opens in our tests the print
> dialogue on KU and I suspect this was a mistake on their part.
> 
> DTDS:
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/ku/rev/baf78810a202#l6.266

That's it! Please file a bug under the localization component and ku. 'P' should really not be used given that we don't differentiate between small and capital letters, and 'p' is assigned for printing.
Anthony, as long as the problem persist, we might want to drop 'ku' from the locales to test.
Summary: testAddMozSearchProvider.js fails with "Disconnect Error: Application unexpectedly closed" → [ku] testAddMozSearchProvider.js fails with "Disconnect Error: Application unexpectedly closed" because the print dialog gets opened
Depends on: 897467
Status: NEW → ASSIGNED
Mario, I see the dependency bug was fixed. Please check this test, thanks.
Flags: needinfo?(mario.garbi)
The dependency bug 897467 was only landed on Aurora and so the problem persists on Beta.
Flags: needinfo?(mario.garbi)
I have tested this again today with Mozmill 2.0.3 and we only hit this issue with ESR24 and not on the other branches.

ESR24 ku:
http://mozmill-crowd.blargon7.com/#/functional/report/40742e0746fd767e6d2fd586598cdeab

Aurora ku:
http://mozmill-crowd.blargon7.com/#/functional/report/40742e0746fd767e6d2fd586598d2307

On Aurora ku we have a similar issue as in Bug 951208 for which I will log a separate bug
I don't think this will be fixed on ESR24 soon, most likely will get merged in time. I suggest we skip it on this branch, if Anthony would still want to run tests against 'ku' builds.
Would be great if we could implement soon the specific-locale skip :)
(In reply to Andreea Matei [:AndreeaMatei] from comment #16)
> I don't think this will be fixed on ESR24 soon, most likely will get merged
> in time. I suggest we skip it on this branch, if Anthony would still want to

I don't think that this will ever be merged into a ESR branch. But Axel could give better feedback.
Flags: needinfo?(l10n)
Yeah, we don't update localizations for ESR.

I'm a bit surprised and worried that Firefox would hang for a bad command key. I'd expect the wrong dialog to open or the wrong action to take place, but not a hang. Could it be that the testsuite is hanging waiting for the print dialog?

Independent of that, I'll reduce the severity of this bug to normal, just because the affected population is small.
Severity: critical → normal
Flags: needinfo?(l10n)
The hang is part of our Mozmill test which doesn't expect this dialog to appear, so we cannot close it. We could figure out what we could do to get it handled at least for the case when a different dialog gets opened. Andreea would you mind to file a bug for that in the Mozmill component?
Filed bug 957049 for that. 
Mario, please make a skip patch for esr24. I know at some point we mentioned to Anthony that 'ku' is broken, but I'm not sure he stopped running tests on it.
I don't see why we should skip the test on esr24. Lets make sure that we do not run tests for the ku locale instead!
Assignee: mario.garbi → nobody
The dependency bug has been fixed for Firefox 26, so please re-check if we can re-enable the test for this locale.
This has been fixed, I checked on all os platforms, for linux I rechecked locally.
http://mozmill-crowd.blargon7.com/#/functional/report/12a8568e34c97b929089c7a61f27b3d1
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Was it the one and only failure which caused us to not run tests for ku? I ask because I don't see it in the list for locales to test on beta and release at https://github.com/mozilla/mozmill-ci/issues/270.
Flags: needinfo?(cosmin.malutan)
Yes, but as I mentioned in the last Monday meeting, not all locales are covered by the eight batches we have in issue 270. We need to add another one with the ones we missed, and test those too.
Flags: needinfo?(cosmin.malutan)
Ok, so please comment on the issue, and list the locales we have to get added. Thanks.
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.