Closed Bug 611052 Opened 14 years ago Closed 14 years ago

[hebrew]undo close group option is not coming up after a tab group is closed

Categories

(Firefox Graveyard :: Panorama, defect, P3)

x86
macOS
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: prasad, Assigned: aza)

References

Details

(Keywords: rtl)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 unable to undo the action close tab group Reproducible: Always Steps to Reproduce: 1.launch firefox and open a tab at any URL 2.go to TabCandy view and close the group which contains the tab 3.group is closed successfully Actual Results: There is no link "Undo close group" seen in tab candy pane Expected Results: there should be a link "undo close group" to get back the closed group
I can confirm this on 10.6, 4b7 as well. I tried creating multiple groups and closing them, but the "undo close group" button never shows up. The error console has entries like: שגיאה: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIStringBundle.GetStringFromName]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://browser/content/tabview.js :: tabviewString :: line 33" data: no] Nominating for blocking because this is important functionality missing in this locale. I didn't try other RTL locales.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: rtl
The problem is that the following line is missing in the properties file in the hebrew version. chrome://browser/locale/tabview.properties > tabview.groupItem.undoCloseGroup=Undo Close Group
If comment 3 is correct, it doesn't seem like something we can fix in Tab Candy. Assigning to Aza to direct to the right person. Localization?
Assignee: nobody → aza
Blocks: 608028
Priority: -- → P3
Cc'ing l10n for processing, canceling blocking request.
blocking2.0: ? → ---
The missing line should be added as part of l10n-merge, so that'd be a non-issue. There could be something else happening: it's assuming a RTL locale, and does some pixel shifting for that, and then ends up with a LTR english padded string which goes off the wrong way. I'd expect more visual disturbance, though.
(In reply to comment #6) > The missing line should be added as part of l10n-merge, so that'd be a > non-issue. > > There could be something else happening: > > it's assuming a RTL locale, and does some pixel shifting for that, and then > ends up with a LTR english padded string which goes off the wrong way. I'd > expect more visual disturbance, though. This doesn't have anything to do with RTL, I don't think. We just fail to read the string, but that's really odd, since the string seems to be here: <http://hg.mozilla.org/l10n-central/he/file/36f85099a224/browser/chrome/browser/tabview.properties>. Tomer, can you please see if you can reproduce it on the beta7 Hebrew build, and if so, can you paste the contents of chrome://browser/locale/tabview.properties in that build? Also, if you have multiple windows open and search in Panorama for the title of a tab open in another window, do you get a horizontal bar at the bottom containing the result, prefixed by "Tabs from other windows"?
Checked with hebrew 4.0b7 version and following is noticed: Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b7) Gecko/20100101 Firefox/4.0b7 chrome://browser/locale/tabview.properties tabview.groupItem.newTabButton=לשונית חדשה tabview.groupItem.defaultName=תן שם לקבוצת לשוניות זו… tabview.search.otherWindowTabs=Tabs from other windowstabview.groupItem.undoCloseGroup=Undo Close Group Note that the new line is missing in properties for "tabview.groupItem.undoCloseGroup" This also results another issue: search in Panorama for the title of a tab open in another window shows the result prefixed with "Tabs from other windowstabview.groupItem.undoCloseGroup=Undo Close Group" see attached image
Doh, the English file didn't have a newline at the end, so compare-locales added it without, too. The English file has a newline now, so this won't come up again here. Filed bug 612619 on compare-locales to actually fix the cause in the backend. Always good to learn that l10n-merge doesn't fix everything. I'm marking this FIXED, which is as close as anything else, it's just not going to show up anymore as is, and of course not in the final product where we don't use l10n-merge.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: