Dialog size testing
Ehsan Akhgari
As I understand it, one of the things to test in any localization is
dialog size testing, to ensure that all of the dialogs in the
application and wide and tall enough to contain all parts of the UI
with the translated strings. I was wondering if there is any check
list available for this kind of testing so that we can be sure to not
leave out any dialog. Also, if neither of the members of a
localization team has access to a particular platform (which is the
case with Mac for the Persian l10n team), is there any other person to
ask for help for testing the dialog sizes on that platform and report
the results (possibly with screenshots) back to the l10n team?
Thanks!
--
Ehsan
<http://ehsanakhgari.org/>
Robert Kaiser
Would there be some way to write automated tests for this?
I know, we aren't executing any automated tests on L10n builds right
now, but it might actually be a good idea for things like that...
Robert Kaiser
Ehsan Akhgari
Hmm, I'm not sure how can the property we're testing here be tested
automatically.
I think the property, if specified precisely, is whether there are any
cropped XUL elements anywhere in the displayed dialog. (Please
correct me if I'm wrong).
Is there any way to determine this programatically?
At the worst case (assuming the answer to the above question is no),
we could have an extension which would open up every dialog we have in
the application, and provide a simple means for a human tester to test
whether it's being displayed correctly, and if not, which width and
height values may be used to correct the display problem.
--
Ehsan
<http://ehsanakhgari.org/>
Jesper Kristensen
I guess for a checklist, a good place to start would be the places where
you can do something about the size, e.g.:
http://mxr.mozilla.org/l10n-central/search?string=width:
I don't think there are any tools to help you test dialog sizes. It also
might not make much sense to spend too much time to write workarounds
for the bug in xul preventing dialogs from autoresizing instead of
trying to fix it.
Robert Kaiser
> Hmm, I'm not sure how can the property we're testing here be tested
> automatically.
I think some cases can be tested, as e.g. a label growing wider to the
right than the right border of the window/panel (known to happen with
iframes and fixed-width windows) should be detectable via JS, I guess
(comparing left+width or some other indicator of right edge coordinate
with the window width).
Not completely sure what indicators we have for what, but cases like
buttons moving too far down (sometimes far enough to be invisible) could
also be detected, cut-off words might be more difficult.
> At the worst case (assuming the answer to the above question is no),
> we could have an extension which would open up every dialog we have in
> the application, and provide a simple means for a human tester to test
> whether it's being displayed correctly, and if not, which width and
> height values may be used to correct the display problem.
That's surely a good idea, but the more we can do automatically, the
better, IMHO. And I think we should have some basic automated tests for
L10n builds anyway, to e.g. detect windows coming up with XUL errors,
and similar things (ideally we could even detect doubled accesskeys
within the same scope).
Robert Kaiser
Axel Hecht
https://wiki.mozilla.org/L10n:Dialog_sizes is one page that helps with
fixing dialog sizes.
The next thing we have is the coverage extension, which opens a bunch of
dialogs and creates screen shots of those. I had a bunch of test runs
prior to 3.0, I could possibly redo some for 3.1.
The output from back-in-the-days is at
http://l10n.mozilla.org/~axel/screens/ still.
One problem is that it's hard to open modal dialogs in a cross platform
manner, as they don't seem to fire any events that they're up, and they
belong to different windows on mac and other platforms. Pretty tough, no
idea on how to resolve that.
Axel
Ehsan Akhgari
> On 14.03.2009 11:59 Uhr, Ehsan Akhgari wrote:
> https://wiki.mozilla.org/L10n:Dialog_sizes is one page that helps with
> fixing dialog sizes.
This page only lists one dialog (the preferences dialog)... Also, I'm
not sure how to use the bookmarklet for modal dialogs...
> The next thing we have is the coverage extension, which opens a bunch of
> dialogs and creates screen shots of those. I had a bunch of test runs prior
> to 3.0, I could possibly redo some for 3.1.
>
> The output from back-in-the-days is at
> http://l10n.mozilla.org/~axel/screens/ still.
Looks very interesting, is the extension available somewhere from
which we can install try it out?
> One problem is that it's hard to open modal dialogs in a cross platform
> manner, as they don't seem to fire any events that they're up, and they
> belong to different windows on mac and other platforms. Pretty tough, no
> idea on how to resolve that.
Doesn't watching for domwindowopened and then the load even work there?
--
Ehsan
<http://ehsanakhgari.org/>
Axel Hecht
> On Mon, Mar 16, 2009 at 1:48 PM, Axel Hecht<l1...@mozilla.com> wrote:
>> On 14.03.2009 11:59 Uhr, Ehsan Akhgari wrote:
>> https://wiki.mozilla.org/L10n:Dialog_sizes is one page that helps with
>> fixing dialog sizes.
>
> This page only lists one dialog (the preferences dialog)... Also, I'm
> not sure how to use the bookmarklet for modal dialogs...
Actually, most dialogs are hooked on to the pref dialog, so I'm getting
quite a few already. But yeah, currently, there's only that single entry
point. I'm scraping for more by using js to autodetect those dialogs
that get triggered by an element with ID, as I use that to label the
images (which makes the names independent of ordering, and thus better
for version control).
>> The next thing we have is the coverage extension, which opens a bunch of
>> dialogs and creates screen shots of those. I had a bunch of test runs prior
>> to 3.0, I could possibly redo some for 3.1.
>>
>> The output from back-in-the-days is at
>> http://l10n.mozilla.org/~axel/screens/ still.
>
> Looks very interesting, is the extension available somewhere from
> which we can install try it out?
The sources are in my tooling repo,
http://hg.mozilla.org/users/axel_mozilla.com/tooling/, in
extensions/coverage. The build system assumes that you symlink it to
mozilla-central/extensions/coverage, IIRC. I confess, I haven't looked
at the beast in a while.
>> One problem is that it's hard to open modal dialogs in a cross platform
>> manner, as they don't seem to fire any events that they're up, and they
>> belong to different windows on mac and other platforms. Pretty tough, no
>> idea on how to resolve that.
>
> Doesn't watching for domwindowopened and then the load even work there?
No, they're just some panes sliding down on the mac, and in particular
there, I haven't found any kind of signal that would let you know when
it's done sliding.
Patches welcome, with bugs in Mozilla Localizations/Infrastructure (I
watch that component).
Axel
Ehsan Akhgari
>> This page only lists one dialog (the preferences dialog)... Also, I'm
>> not sure how to use the bookmarklet for modal dialogs...
>
> Actually, most dialogs are hooked on to the pref dialog, so I'm getting
> quite a few already. But yeah, currently, there's only that single entry
> point. I'm scraping for more by using js to autodetect those dialogs that
> get triggered by an element with ID, as I use that to label the images
> (which makes the names independent of ordering, and thus better for version
> control).
Well, my point originally was if there is a list of all the dialogs
which would be shown at all. The pref-pane originated dialogs are the
obvious ones, and I'm looking for more obscure ones in fact. :-)
Also, did you see my second question about running the bookmarklet?
> The sources are in my tooling repo,
> http://hg.mozilla.org/users/axel_mozilla.com/tooling/, in
> extensions/coverage. The build system assumes that you symlink it to
> mozilla-central/extensions/coverage, IIRC. I confess, I haven't looked at
> the beast in a while.
Cool, I'll try to give it a look soon. If I can't get the build
system to work, I can always create an xpi manually... :-)
> No, they're just some panes sliding down on the mac, and in particular
> there, I haven't found any kind of signal that would let you know when it's
> done sliding.
>
> Patches welcome, with bugs in Mozilla Localizations/Infrastructure (I watch
> that component).
Ah, unfortunately I don't have a Mac. :-( Do you have problems on
Windows or Linux?
--
Ehsan
<http://ehsanakhgari.org/>
Axel Hecht
> On Mon, Mar 16, 2009 at 2:55 PM, Axel Hecht<l1...@mozilla.com> wrote:
>>> This page only lists one dialog (the preferences dialog)... Also, I'm
>>> not sure how to use the bookmarklet for modal dialogs...
>> Actually, most dialogs are hooked on to the pref dialog, so I'm getting
>> quite a few already. But yeah, currently, there's only that single entry
>> point. I'm scraping for more by using js to autodetect those dialogs that
>> get triggered by an element with ID, as I use that to label the images
>> (which makes the names independent of ordering, and thus better for version
>> control).
>
> Well, my point originally was if there is a list of all the dialogs
> which would be shown at all. The pref-pane originated dialogs are the
> obvious ones, and I'm looking for more obscure ones in fact. :-)
There is no way to actually find out the UI-path to all dialogs without
some severe "and I don't even know what". You can't just click and
activate everything, as that's going to break your setup.
> Also, did you see my second question about running the bookmarklet?
From the dialog, you need to get to the chrome url, and then you open
the chrome url a regular browser window. Then you resize that window and
use the bookmarklet. As many dialogs aren't resizable at all, you need
to open them in something that is, main browser window just works. Yay
XUL tech.
>> The sources are in my tooling repo,
>> http://hg.mozilla.org/users/axel_mozilla.com/tooling/, in
>> extensions/coverage. The build system assumes that you symlink it to
>> mozilla-central/extensions/coverage, IIRC. I confess, I haven't looked at
>> the beast in a while.
>
> Cool, I'll try to give it a look soon. If I can't get the build
> system to work, I can always create an xpi manually... :-)
Carefully look at the prefs it has, in particular the output path. That
thing isn't designed to be used without care ;-)
Thanks.
>> No, they're just some panes sliding down on the mac, and in particular
>> there, I haven't found any kind of signal that would let you know when it's
>> done sliding.
>>
>> Patches welcome, with bugs in Mozilla Localizations/Infrastructure (I watch
>> that component).
>
> Ah, unfortunately I don't have a Mac. :-( Do you have problems on
> Windows or Linux?
I know that windows is tricky due to being modal, so you need to spin
additional event loops, IIRC, and stuff.
I really don't know for sure.
Axel