Closed Bug 452327 Opened 11 years ago Closed 6 years ago

Create XUL app or extension to mirror major update window

Categories

(Testing :: General, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: samuel.sidler+old, Unassigned)

Details

Attachments

(2 files)

In testing the major update window, we had to check a number of locales on a number of OSes/platforms to see if the content fit inside the window just perfect. Pascal created a webpage to do most of this, but we found further problems when testing on the actual website using real builds.

We should have an extension or XUL app that is simply the major update window with a one-button push for showing or hiding the extension out of date issue.

I envision:

   -------------------------------------------
  |                  _____                    |
  |   Enter locale: |_____|                   |
  |    __           __                        |
  |   (__Show Notice__)                       |
  |                                           |
  |   _____________________________________   |
  |  |                                     |  |
  |  |                                     |  |
  |  |        Update window                |  |
  |  |                                     |  |
  |  |_____________________________________|  |
  |___________________________________________|


Since we're going to be testing this for every new major update, it'd be nice to have a way to really test it.

Is this doable?
Oh, and it in case it wasn't clear, this should probably pull from trunk or just have a user-changeable URL where it could pull from to test.
Can you go over some of the issues you ran into besides the need to test each of the locales? For example, what changes had to be made (if any) for any of the locales or what changes had to be made at all from the results found during the testing?

Perhaps we could force a minimum width in px on this ui and make the details and license contents a fixed size that works with that minimum width and center it? This would allow the locales to specify a width that would allow increasing the width.
(In reply to comment #2)
> Can you go over some of the issues you ran into besides the need to test each
> of the locales? For example, what changes had to be made (if any) for any of
> the locales or what changes had to be made at all from the results found during
> the testing?

The design that was made (which changes for each release so far) is designed specifically for that window. Once we change any text (like, for each locale), it causes a horizontal scrollbar in the UI. Additionally, some of CSS caused a vertical scrollbar when the content clearly fit visually, but was maybe two pixels off technically.

> Perhaps we could force a minimum width in px on this ui and make the details
> and license contents a fixed size that works with that minimum width and center
> it? This would allow the locales to specify a width that would allow increasing
> the width.
> 

From my understanding, I think the locales can already specify a width for their window in ems. I'm not sure about that though. Pascal?
(In reply to comment #3)
>...
> From my understanding, I think the locales can already specify a width for
> their window in ems. I'm not sure about that though. Pascal?
They can

I was referring to enforcing a minimum size to prevent scrollbars.

So, each locale has its own details page served up or is the content the same for all of them?
Each locale has it's on localized details page but the content is the same. The localizers can specify a specific width in em to the whole dialog, but have no control on the frame inside this window that displays the external web page. The size of this frame is not fixed and depends on several factors like the default font size, the width of the dialog for the platform (we have a specific setting for Mac) and some other constraints.

a couple of notes:

iirc the height and width of a wizard is not sized differently on a per locale basis on Windows.

the current wizard on windows is not the standard size on windows.
I promised Sam I'd come up with an extension to help make testing this easier.  Well...little did I know what I'd gotten myself into.  Here is the extension.  It's not really optimal for a lot of reasons but here are the ones that I had to work around in some pretty spectacularly bad ways:
* the XUL for the update dialog is different between 2.x, and 3.0.x that means that this version (templetizing the 2.0 version will work for our next major update (from 2.x to 3.0.x) but will need to be updated for future use)
* the update wizard content is very much generated on the fly, so we can't just throw up a static representation, I had to also take much of the javascript, modify small parts of it to show the proper page that we are interested in and modify other parts of it so that it will show the extra window
* We only display one locale per build. So, I have loaded the other locales into chrome content space and refer to them from the templetized XUL files.  
Yeah...hacky.
* We handle en-US differently from all other locales.  So to templetize that locale, I had to just generate the XUL by hand and use chrome:// URLs, so that assumes that the tester is running a en-US build.  This could be worked around with more hackery but, I wanted to go ahead and get a version out to see the light of day.

So, here is how it works:
The tester gets a file that contains the locales he/she is interested in testing, along with the URLS to the page to display for the update.  This URl is the "detailsURL" specified in the AUS string.  It is something like this: http://www.mozilla.com/en-US/firefox/3.0/details/  The file is formatted with a locale and a details URL for that locale on one line, separated by a space.  An exmaple file is included in the extension (locale-file.txt)

Next, the tester runs the update-xul-generator.py script which will do the following:
* It will take the provided file and parse it
* It will take a directive for where the l10n files should be pulled from (either cvs (for 3.0 and 2.x testing) or from Hg (for future 3.1 testing))
* The python script will create a javascript object for the extension to use as a list of locales and associated detail URLs.
* The script will check out all the necessary files
* The script will use a templetized XUL file and generate two XUL files for each locale, substituting in the chrome://l10n/content/<locale> locations for the necessary DTD and properties files
* The script will also generate two XUL files for each language, one with sizing directives for windows and linux, and one with sizing directives for mac.

Once this is all done, the tester can then re-zip the XPI and install it in a build.  For testing Firefox 2.x.x.x to 3.0.x major update, you'd install it in Firefox 2.x.x.x, for example.  Under the Tools menu is a "L10N Update Checker" entry, and that will bring up a page with buttons where you can toggle through the different dialogs in each language, and you can toggle the "extension information" pane as well.

A note about the extension information pane.  When you click the "show extra text" button, it will re-use your last selected choice of locale and operating system size directive.  So, if you last viewed de-win then the extra text will display on a de-win sized dialog.

So, that's the beast.  Of course, I'll be happy to generate the extension with the python script if you give me a file with the locale and detail URLs. Generating the script does assume that you have several items installed: python, cvs, and hg, for example, which Joe Tester might not have on his/her box.

I'll upload the extension in zippy format with my faked list of locales - my list contains fr, de, en-US, and ja.  Unzip it to see the generators and the templates.
Attached file The extension
Here's the extension.
Deprecating Testing :: Infrastructure, and this sounds like it was completed.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Component: Infrastructure → General
You need to log in before you can comment on or make changes to this bug.