If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

The "Update Minefield" Button Shifts To The Right When Clicked




Application Update
8 years ago
8 years ago


(Reporter: WildcatRay, Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)




8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090612 Minefield/3.6a1pre Firefox/3.0.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090612 Minefield/3.6a1pre Firefox/3.0.11

In the browser Software Update dialog box, when I clicked on the Update Minefield button, it shifted to the right before the dialog changed to the download monitor dialog similar to what used to occur in Firefox 2. This occurred in the 20090611 Trunk nightly.

Reproducible: Always

Steps to Reproduce:
1. Click on Help > Check for updates...
2. In the Software Update dialog box that alerts user to availability of a browser update, click on the Update Minefield button.
Actual Results:  
The Update Minefield button shifts to the right before the dialog changes to the browser download monitoring dialog.

Expected Results:  
The Update Minefield button should only show the button press animation.

I thought I saw this in the 20090611 Shiretoko nightly when trying to update it, but if it is there, too, it is doing so very quickly making it difficult to be sure it is happening.


8 years ago
Version: unspecified → Trunk
I didn't notice this this morning. Did you try in safe mode?

Comment 2

8 years ago
(In reply to comment #1)
> I didn't notice this this morning. Did you try in safe mode?

No, I did not. I have not had time to go back and forth testing this. Another user reported in the daily Trunk thread that he, too, saw the button shift. Also, FWIW- I saw it on both of my computers.


8 years ago
Component: General → Application Update
Product: Firefox → Toolkit
QA Contact: general → application.update
Yeah, confirmed, I see this too (Windows Vista). Is something from 10 Jun 2009, indeed.
Ever confirmed: true

Comment 4

8 years ago
I have seen it in both the 20090611 and 20090612 builds, the latter one done using a no frills profile (no themes and only the Java Quick Starter and Java Console extensions).
i looked for a regrange using the hourlies from http://hourly-archive.localgho.st/hourly-archive2/mozilla-central-win32/
=> range: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1057ca8f2a91&tochange=cabb8925dcd3
=> caused by Bug 178324

can someone check other OS please?
Blocks: 178324
Component: Application Update → XUL
Keywords: regression
Product: Toolkit → Core
QA Contact: application.update → xptoolkit.widgets

Comment 6

8 years ago
How would I go about testing this?
Just run yesterdays build and perform a manual update.

Comment 8

8 years ago
(In reply to comment #7)
> Just run yesterdays build and perform a manual update.

I want to know how to test this in my build. Currently, I just get a no updates found message.
I don't know anything about your build Neil. So download a build from 0612 or 0613 and you should find a full or partial update.
Presumably he wants to test it in a debug build.

This code snippet seems to work OK:
var update={
  type: "minor",
  QueryInterface: function (aIID) {
    if (aIID.equals(Ci.nsIUpdate))
      return this;
    throw "foo";
var ary = Cc["@mozilla.org/supports-array;1"].
var ww = Cc["@mozilla.org/embedcomp/window-watcher;1"].
var w = ww.openWindow(null, "chrome://mozapps/content/update/updates.xul", "",
              "chrome,centerscreen,dialog=no,resizable=no,titlebar,toolbar=no", ary);
setTimeout(function () { w.setCurrentPage("updatesfound"); }, 1000);

Comment 11

8 years ago
The issue here is because the Update button on the earlier page is displayed in bold and just before switching to the 'downloading' page the button is changed to display normally.

Likely, the layout flush that occurs when checking if something is focusable (the button for the next pane) triggers a repaint earlier, whereas no flush was occurring before.

I don't know the update code at all so I don't know what should be happening here. Perhaps the bold should never be removed, or removed later?
Component: XUL → Application Update
Product: Core → Toolkit
QA Contact: xptoolkit.widgets → application.update
Will take care of this in bug 476501
Depends on: 476501

Comment 13

8 years ago
I swear the entire dialog moved, not just the button.

Updated from 20090613 trunk nightly to 20090615 nightly on vista
Kurt, huh. Something similar to bug 497986? But this is branch. :S

Comment 15

8 years ago
(In reply to comment #14)
> Kurt, huh. Something similar to bug 497986? But this is branch. :S
Nevermind, I think it was just the dialog getting focus and on vista the "glow" around the window kind of looked like the dialog also moved.  Probably just me being tired though.  And the bug is also on the trunk, not just a branch bug.

Here is a screencast just in case it is needed that I took when I thought the whole dialog moved.  http://screencast.com/t/6E1AdROI
I can't reproduce this anymore. If somebody else can, please reopen.
Last Resolved: 8 years ago
No longer depends on: 476501
Resolution: --- → WORKSFORME
V. with Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091031 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20091031042521

Comment 18

8 years ago
I am not seeing this either (WFM now).
Last Resolved: 8 years ago8 years ago


8 years ago
You need to log in before you can comment on or make changes to this bug.