Closed Bug 1026582 Opened 7 years ago Closed 7 years ago

Test failure in testSessionStore.testUndoTab.testUndoTabViaShortcut for [hsb] locale


(Mozilla QA Graveyard :: Mozmill Tests, defect)

Version 2
Windows 7
Not set


(firefox31 wontfix, firefox32 fixed, firefox-esr31 wontfix)

Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox-esr31 --- wontfix


(Reporter: lizzard, Unassigned)




(Whiteboard: [mozmill-test-failure])

I'm looking at the code but I'm not sure I understand how the localization could create the failure. Aren't you using the IDs of the context menu to activate commands?
Out of curiosity I just downloaded the build linked in for OS X: both menu and shortcut work fine to reopen the last closed tab.
(In reply to Francesco Lodolo [:flod] from comment #2)
> Out of curiosity I just downloaded the build linked in
> for OS X: both menu
> and shortcut work fine to reopen the last closed tab.

The problem we haven't seen on OS X, but only for Windows. Please see the report URL as given by Liz in comment 0. The DTD entities look fine, so maybe we are facing an issue (like bug 1005942 for Firefox 29.0) in reopening recently closed tabs.

Andreea, it would be good if someone could check that.
OS: Mac OS X → Windows 7
Hardware: x86 → All
This fails because we have an conflict in access keys in browser.dtd:
tabCmd.commandkey "t" === pageSourceCmd.accesskey "t"

Instead of restoring a the previous closed tab here it opens the page source, this can be observed visually when running the test.
I'm lost in Mozmill territory. From the first link, I get here

Which tells me that the failing test is "testUndoTabViaShortcut".

The only method that seems interesting is tabBrowser.reopen("shortcut")

But the JS seems to use tabCmd.commandkey

I don't see any relation between a commandkey and an accesskey.
Me neither. Not sure why this assumption has been made. Both are totally independent, and wont harm each other.
It actually toggles the webConsole, and it should restore an closed tab, I assumed it was a conflict.
In bug 1026990 - - I wrote yesterday that I thought that the keytext key for the web console is an accesskey and changed it. I translate on Pootle an changed the key for Fx 32.0a2 Aurora there. But I don't have access to mozilla-central so I ask that someone of you changes this for Fx 31.0b2. Thanks
Michael, we have to keep that conversation on bug 1026990. Over there I requested help from Francesco. So lets see that we can get this in soon. Thanks for your fix!
Hello Henrik, I saw this bug by chance and since I didn't got a reply on bug 1026990, I wanted to be on the safe side, true to the motto: Two are better than one. :-)
Failure is still happening in the latest Beta builds.
Hello Liz, hello Anthony. Who can change it? I have right for Pootle only but Pootle translations are for Fx 32 Aurora. See bug 1026990:

Or can I get the rights for mozilla-central to change it myself? I don't want that the Upper Sorbian Firefox 31 is not released because of this bug.
Michael, don't worry about mozilla-central: hsb/dsb are not even available there.

Also, it's too late to accept new changes for mozilla-beta, and I think hsb it's already included in the release that will come out next week. If you fixed it on aurora, it will move to beta next week automatically.
Thank you Francesco. I am glad to hear that. But, I changed it for Fx 32 Aurora only because the bug was filed only after Fx 32 has already been on Pootle.
This failed again today for Firefox 31.0 hsb on mm-win-81-32-3 (2014-07-17_12-39-55). The failed test is testUndoTabViaShortcut from /testSessionStore/testUndoTab.js with the error message "New tab has been opened".
Who can change that still for Fx 31? Who creates the builds? What is the used source?
Given Francesco this is a wontfix for Firefox 31, given that we are too late in the cycle. But might be able to fix the bug in the next esr release? Francesco, is that possible?
A question: Is it possible to fix the bug at least for the Fx 31 language pack?
(In reply to Michael Wolf from comment #19)
> A question: Is it possible to fix the bug at least for the Fx 31 language
> pack?

Lets ask Axel and Flod, who should know.
Flags: needinfo?(l10n)
Flags: needinfo?(francesco.lodolo)
As I said the sign-off process ended last Monday for Firefox 31, that includes both the build and the language pack (there are no separate sign-offs).

As far as I know, the same thing is valid for Firefox ESR, but I'm not completely familiar with the process.
Flags: needinfo?(francesco.lodolo)
Yes, but the bug has already been filed on June 17, 2014 and already on June 19, 2014, 2 days later, I've given the solution. Since then nothing happened, except that someone has pointed out that the bug is not fixed yet.
We're not going to get this fixed in 31, and we're not taking updates for localizations on ESR either.

The fix for this bug is going to be in 32, I verified that by looking at the source we'll ship to betas next week.

Resolving this bug as FIXED, updated the flags.
Closed: 7 years ago
Flags: needinfo?(l10n)
Resolution: --- → FIXED
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.