337980 - Progress of install keeps disappearing/flickering

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Dave Townsend [:mossop]]

During an extension installation the text below the progress bar saying the amount download keeps disappearing and reappearing causing the height of the bar to jump up and down in an irritating fashion.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060513 Minefield/3.0a1 ID:2006051302

Comment 1

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

Since this only happens on trunk and a regression range would be helpful in identifying the root cause

Comment 2

[djpohly]

This bug was present as soon as the new EM was landed on trunk (bug 329045).  Strange that it works fine on the 1.8 branch--sounds like the problem might lie somewhere outside the EM code proper.

"Regression" window:
2006-04-26 04: Pass
2006-04-27 06: Fail
http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=2006-04-26+04%3A00&maxdate=2006-04-27+06%3A59

Comment 3

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

Yes, something changed on the trunk and when the ui update landed it became apparent. The regression window only shows that the ui update was landed and doesn't show what actually changed underneath that exposes this bug. I won't have time to look at this for at least another month or more - it is impossible to say I will have time to look at this then even - so if anyone wants to take this on please do.

Comment 4

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

In other words it would be a good thing to find the checkin that created this difference between trunk and branch that causes this bug.

Comment 5

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

Removing the block. Something else regressed or changed on trunk that breaks this on trunk which needs to be identified.

Comment 6

[djpohly]

I built a 2006-04-20 04:00 Firefox with the add-ons patches applied, and it still exhibits the bug, so the trunk regression occurred before then.

Is this the right way to go about finding this regression?  It's a lot of work (on my laptop's part), but it seems necessary.  If so, that's fine: building Firefox is great fun!

2006-04-10 currently in progress.

Comment 7

[djpohly]

Build from 2006-03-20 still flickers.  I've tried backing up to 2006-03-10 and end up with build errors.  Anybody have suggestions as to another way I could try to pin this down?

Comment 8

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

Devin, sorry for not replying earlier... it is just that there is no good answer to being able to pin down a regression that has gone undiscovered for so long. Besides checking out from cvs by date there is http://archive.mozilla.org/pub/firefox/nightly/

Comment 9

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

roc and bz, I wonder if either of you could track down why this occurs on trunk and not the 1.8.1 branch?

Comment 10

[Boris Zbarsky [:bzbarsky]]

I'm not likely to be able to do so for the foreseeable future.... (which at this point is extending well into the fall).

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I suggest you create a minimized standalone XUL testcase, and try using that with archived builds to find the exact regression date.

Comment 12

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

Attachment: patch

Comment 13

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

robert, for my own benefit:  

how does your patch work around the problem?  Does giving the label a default value ("Waiting...") prevent the disappearing / flickering?  Does this mean we'll see "Waiting..." when we wouldn't before?

Also, what's the purpose of the extension.js change?

[from previous comments, it sounds like this regression is caused by some other change in layout.  once this lands, could you log a spin off bug on the regression.  if devin's regression window from comment #2 is correct, perhaps it was one of roc's changes to layout?]

Comment 14

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

There have been several changes both to layout and how templates work. For example, the symptom has changed from the one initially reported... it now doesn't show anything for the amount downloaded and no longer flickers.

(In reply to comment #13)
> how does your patch work around the problem?  Does giving the label a default
> value ("Waiting...") prevent the disappearing / flickering?  Does this mean
> we'll see "Waiting..." when we wouldn't before?
After the download starts there can be several seconds before any download progress. This change makes it so Waiting is displayed instead of nothing at all. The initial binding with the waiting... text is no longer in use since the download started. Without this we get the following sequence:

Extension Name
Waiting...

Extension Name
[                      ] <- progress bar

Extension Name
[                      ] <- progress bar
x KB of x KB

With it we get:
Extension Name
Waiting...

Extension Name
[                      ] <- progress bar
Waiting...

Extension Name
[                      ] <- progress bar
x KB of x KB

Which is much cleaner IMO

> Also, what's the purpose of the extension.js change?
Previously iirc we had to specify the attribute in the template to accomplish this and now if we do we are unable to specify the value on the element for it to be picked by the binding. This may be due to the fix for bug 331689. Note I believe the new behavior is more correct.

> [from previous comments, it sounds like this regression is caused by some other
> change in layout.  once this lands, could you log a spin off bug on the
> regression.  if devin's regression window from comment #2 is correct, perhaps
> it was one of roc's changes to layout?]
That regression range is from when the add-ons mgr. was first landed which exposed this bug and not the root cause. I believe the root cause is due to a change in layout due to several other trunk regressions due to layout changes that also affected the add-ons mgr. At this time I believe this bug may have been caused by changes to how templates work. I'll spend some time on trying to verify it but until I have more details I'm not going to file a spinoff.

Comment 15

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

Comment on attachment 237594 [details] [diff] [review]
patch

r=sspitzer

thanks for the detailed explanation.

Comment 16

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

Checked in to trunk