354789 - get different major update description content based on em.getIncompatibleItemList

Status: RESOLVED WORKSFORME

(Toolkit :: Application Update, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Bug 349590 pointed out that in cases when a major update is available but may be incompatible with add-ons, the warning message that we show users reduces the available space for describing the upgrade. That bug was marked WONTFIX since cbeard, pkim and I decided that even the small space was acceptable.

However, it would be nice if we could show different content that's tailored to that small space when needed, and content that fits the larger space when the warning doesn't exist. Amongst other things, it would keep an ugly scroll bar from appearing and throwing off the width of the window ...

I spoke with Seth, and there were three ways we could think of doing this:

1. Using JS, have the update description content determine the size of the window and show/hide content as appropriate. If JS is disabled on the client, this wouldn't work.

2. Don't show the scrollbar, and tailor the content so that one part appears "above the fold" (the cutoff point in the smaller size) and another additional part appears below. It would appear to be two different versions of the same content.

3. Add a parameter to the URI used to fetch the upgrade description (such as &incompat=yes) when we detect that we've failed the compatibility check. This would mean moving some code around in updates.js (see LXR link in URL) so that we do the compat check before fetching the update, and then format the URI depending on the results of that check.

1 & 2 are server-side and really safe, but 3 is a much more "pure" way to do things, and probably makes things easiest on the "creating that update description HTML" side of things.

Comment 1

[Daniel Veditz [:dveditz]]

This is a scary thing to block on when the code hasn't even been written and it's assigned to nobody. And rejected for the ongoing 1.8.1 branch!

Feel free to renominate, but I really don't feel comfortable taking code that hasn't been tested in FF2 given the near absence of community QA on the 1.8.0 branch. A 3-4 person in-house QA team can only do so much. Moving nomination to 1.8.0.9 when presumably this will have been landed in 2.0.0.1 as well.

Comment 2

[Daniel Veditz [:dveditz]]

Not going to block 1.8.0.9, if it lands in the 2.0 branch at some point (2.0.0.1 seems extremely unlikely) you can ask for approval on the patch. Speaking of which, you should fix this on the trunk first ;-)

Comment 3

[(not reading, please use [e-mail] instead)]

sorry for the bug spam, re-assigning bugs back to default owner if I'm not working actively on them.

Comment 4

[Robert Strong (they/them - no direct email)]

The UI now has a separate page for incompatible add-ons after the checkin of bug 324121. Resolving -> wfm.

If this change isn't adequate as far as this bug goes please reopen or file a new bug.