seen with Firefox Sync 1.6.2 on Firefox 3.6.13 on Mac. Buttons in lower right not visible. Particularly the Next button. Hitting enter here does move through the dialog. So not entirely stuck.

fr on XP is partially affected by this bug. just a bit of the Next button shows.

This is addon (3.x) only or does this affect Firefox 4.0 as well?

Checked ja-JPmac on beta11, this bug is present there as well.

Thanks. I think there's two things to this: 1. In the addon UI we made the setup title text wrap (bug 608807) but we never ported that to the Firefox 4.0 UI (bug 609160). We should fix that. I believe that will fix the fr locale here. Tracy, could you check whether the fr locale has the same problem in the addon? 2. As far as I can tell, the Japanese string doesn't contain any spaces so even if we fixed bug 609160 (which we should!), it probably wouldn't wrap. I'm not entirely sure what the best course of action is here. CCing Axel for some input.

fr on XP was with the add-on. I'd guess there are other locales affected. I can't check them all. 2 of 4 tier 1 locales affected isn't good.

(In reply to comment #5) > fr on XP was with the add-on. Oh right. Never mind :)

Can we re-use the concepts in the preferences dialog crop mozmill test to create a similar automated test for this UI? http://hg.mozilla.org/qa/mozmill-tests/file/default/firefox/l10nTests/testCropped has sources. Also, do we know what the problem is right now? I haven't done any sync setup things in a while, so I'd need STR. Also, I'm doing FOSDEM this weekend/travel on monday. (Same for Henrik, if you're wondering.)

Basically, extra-long wizard title. Not sure what the right fix is. (Just crop over-long labels? Provide a different screen?)

Blocks Sync in Japan, blocks the product!

FWIW, line wraps don't require latin spaces, there's more to scripts that i18n line wrapping can handle. We should definitely try to enable the line to wrap. I assume it doesn't, that is.

Axel, is there a best practice for wizards like this? We're just using a straight wizard element, albeit with some extra styling. Do other wizards wrap/crop?

No idea, sadly.

(In reply to comment #11) > Do other wizards wrap/crop? They don't. This is a problem with wizard.xml. Fortunately I have a fix which I will upload in bug 609160.

Here's the sync setup wizard running without syncSetup.css and syncCommon.css. Proof that this isn't our wizard styling messing things up.

Patch uploaded to bug 609160, pending review from Enn. It fixes the problem at its core, the wizard widget binding. Once we agree that this is the right way to solve this problem, we should probably move the blocking flag over to that bug.

I just landed bug 609160. Do we do localized nightlies or how can we verify that this issue is solved in Japanese builds?

Localized fx4 nightlies are on http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central-l10n/.

Yep, this is fixed, tested on mac/win nightlies.

Philipp, this bug is still in the extension. Will bug 609160 not be ported to the branches?

(In reply to comment #20) > Philipp, this bug is still in the extension. Will bug 609160 not be ported to > the branches? Probably not. I've reopened bug 608807.

Still in Firefox 13

Let's just kill the captcha already...