265085 - Software update (green) icon displayed/appears/flashes directly next to Help during start

Status: VERIFIED FIXED

(Toolkit :: Application Update, defect)

Description

[Ger Teunis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041018 Firefox/0.10.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041018 Firefox/0.10.1

When starting FireFox, the software update icon (green) is displayed directly
next to the Help menu even when no update is available.
When Firefox is loaded the update icon disappears (or if a update is available
the arrow will still be visible but align right). This is especially visible on
somewhat slower computers or a new FF install.

Reproducible: Always
Steps to Reproduce:
1. Close Firefox
2. Open Firefox
3. Look direcly next to the Help menu

Actual Results:  
The software update icon (green one) is displayed directly next to help, if FF
is fully started the icon will be alligned right and if no updates are available
the icon will be hidden.

Expected Results:  
No software update directly next to the help menu.

On FF start do not show update icon, after start show the icon if updates are
available (aligned right).

It isn't a big issue but will the loading a FF a bit jumpy (icons appearing and
disappearing during start).

Comment 1

[Ger Teunis]

Attachment: screenshot

Comment 2

[Ger Teunis]

Sorry for the bugspam. Some more info.
The icon is also displayed and on the wrong position when the "Firefox is not as
your default browser" dialog is displayed. After the user chooses Yes or No the
icon disappears and/or is displayed on the right position

Comment 3

[Milen A. Radev]

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041021 Firefox/1.0.

This happens on openning new windowsm also.

Comment 4

[Bill Gianopoulos [:WG9s]]

My guess is that this is caused by some customization you have performed on your
toolbars.  Particularly not having a flexible space where one should be.

Can you duplicate this with a clean profile without doing any customization first?

If not, I would suggest you exit Firefox and delete the localsotre.rdf file from
your profile.

That will probably celar up this issue.

Comment 5

[Ger Teunis]

(In reply to comment #4)
> That will probably celar up this issue.

I already tried a clean profile and even a clean application dir (ofcourse :-))

Please check it yourself, the best way to check the problem is registering IE as
default browser and start firefox, you'll see the update icon being displayed
during the default browser dialog (shouldn't be) directly next to help.

Comment 6

[Phil Ringnalda (:philor)]

*** Bug 267437 has been marked as a duplicate of this bug. ***

Comment 7

[Phil Ringnalda (:philor)]

*** Bug 268654 has been marked as a duplicate of this bug. ***

Comment 8

[Phil Ringnalda (:philor)]

From dup bug 268654 : "is displayed for short each time you open Firefox when
automatic updates are disabled." Even if it's not possible to get it hidden
close enough to when it first appears to not be noticeable when update's
enabled, not showing it at all when it's disabled would be less confusing/worrisome.

Comment 9

[franz.ose]

The icon also appears short before any update-search ends, even if there's no
update.

Comment 10

[Ger Teunis]

(In reply to comment #9)
> The icon also appears short before any update-search ends, even if there's no
> update.

I've reported that one in bug 268803 a while ago.
(not confirmed yet)

Comment 11

[José Jeria]

*** Bug 282775 has been marked as a duplicate of this bug. ***

Comment 12

[Radek 'sysKin' Czyz]

I discussed it on irc with Callek and he came up with the answer: when update
toolbarbutton is first created, its update count is not initialized. The skin
applies visible style to such button, and update JS sets the correct update
count later.
Two solutions:
1) Skin update: make uninitialized update button also invisible.
classic.jar/skin/classic/mozapps/update/update.css

- toolbarbutton[type="updates"][updateCount="0"]
+ toolbarbutton[type="updates"][updateCount="0"], 
+                 toolbarbutton[type="updates"]:not([updateCount]) {
 visibility: collapse
}

2) Initialize the update count as soon as you create the update element
http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.xul#148

- <toolbarbutton type="updates" id="softwareupdate"/>
+ <toolbarbutton type="updates" id="softwareupdate" updateCount="0" />

Whichever is chosen, opening new windows is faster and nicer and no things jump
around. Highly recommended. ;)

Comment 13

[José Jeria]

*** Bug 293035 has been marked as a duplicate of this bug. ***

Comment 14

[Ger Teunis]

Attachment: Radek Czyz's option 2 patch

I personally would go for Radek Czyz's option 2.
Not making this bug theme specific.
(my first patch, please bare with me)

Comment 15

[Justin Wood (:Callek)]

Attachment: Option 2

I of course would prefer a toolkit/ solution.

I do have some reservations about this one, as I very vaguely recall that there
are/were some dynamic use problems with :not; as such I will have an option 3
patch along these lines coming up.

Note to bryner, the browser/ patch may optionally be applied with one of these
toolkit ones, though if you use one of these toolkit patches it is pointless.

Also my two toolkit patches (Option 1, and Option 3) are mutually exclusive, r+
the one you want to add-in.

Comment 16

[Justin Wood (:Callek)]

Attachment: Option 1

I of course would prefer a toolkit/ solution.

I do have some reservations about this one, as I very vaguely recall that there
are/were some dynamic use problems with :not; as such I will have an option 3
patch along these lines coming up.

Note to bryner, the browser/ patch may optionally be applied with one of these
toolkit ones, though if you use one of these toolkit patches it is pointless.

Also my two toolkit patches (Option 1, and Option 3) are mutually exclusive, r+
the one you want to add-in.

Comment 17

[Justin Wood (:Callek)]

Comment on attachment 182805 [details] [diff] [review]
Option 2

damn network timeout coupled with a typo

Comment 18

[Justin Wood (:Callek)]

Attachment: Option 3

Option 3

Comment 19

[Sam Allen]

This WFM on both computers I tried it on in the latest Deer Park nightly.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050617
Firefox/1.0+

Comment 20

[u88484]

This also works for me with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.9a1) Gecko/20050816 Firefox/1.0+ and has worked for over two or three weeks
now...should be closed

Comment 21

[Grey Nicholson (they/them)]

(In reply to comment #20)
> This also works for me with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
> rv:1.9a1) Gecko/20050816 Firefox/1.0+ and has worked for over two or three weeks
> now...should be closed

Yeah, I'm fairly certain the new software update UI (bug 290390) removed the
update icon altogether.