312587 - Menus stop working when Software Update window is frontmost

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P1)

Description

[Dave Miller [:justdave]]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051015 (No IDN) Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051015 (No IDN) Firefox/1.4.1

When the Software Update dialog is frontmost, none of the menus work.  This
bites when the automated update pops up, and you want to see what all windows
you have open in order to decide whether to go ahead and install it now or tell
it to do it later, since you can't look in the Window menu to see which windows
are open.

Reproducible: Always

Steps to Reproduce:
1. Check for updates
2. While the update dialog is frontmost, try using the menus
3.

Actual Results:  
The menu titles highlight, but no menus drop down

Expected Results:  
The menus should still work, but irrelevant items should be grayed out.  Since
Software Update is modeless, the Window menu in particular should still work.

Marking major severity only because we're close to RCs, and this is a poor user
experience.

Comment 1

[Asaf Romano (gone)]

Taking.

Comment 2

[Asaf Romano (gone)]

Attachment: patch [checked in]

Comment 3

[Dave Miller [:justdave]]

I applied the patch and have it building right now, but I just attempted to
reproduce it now in today's build, and can't... the menus are working now.  Is
there a difference between when an update is available and when one isn't?  Or
did this actually get fixed yesterday (and thus why I couldn't find an existing
bug on it? :)

Comment 4

[Dave Miller [:justdave]]

gah, I didn't mean to clear those...  guess that's what I get for reloading the
bug I already had open since I filed it instead of opening it new :)

Comment 5

[Asaf Romano (gone)]

The menus aren't working (without the patch) when the update wizard is focused,
are they?

Comment 6

[Dave Miller [:justdave]]

They are.  But there's no update available right now.  When I noticed the
problem, there was an update available, and the default button was "Restart and
Install" instead of "Done".  I wouldn't think that would matter, but it's worth
noting in case it does.

Comment 7

[Dave Miller [:justdave]]

(In reply to comment #6)

OK, I've had two updates since then now, and I definitely can no longer
reproduce this (even without your patch).  This obviously got fixed somehow
since the build I was using when I reported it.

Comment 8

[Asaf Romano (gone)]

Are you sure the update wizard *is focused*? I can still reproduce this and no
related fix was landed.

Comment 9

[Asaf Romano (gone)]

Oh, and maybe I misinterpret, does File->New Windows work?

Comment 10

[Dave Miller [:justdave]]

I'm most definitely getting menus now, even with the Software Update wizard focused.

However, now that you mention it, you are correct, nothing in the menus actually
works (including trying to switch to a different window with the window menu).

Comment 11

[Asa Dotzler [:asa]]

Not going to block the release on this bug but if you all come up with a safe,
fully reviewed patch, verified on the trunk, then we'd consider it for inclusion
in the release.

Comment 12

[Asaf Romano (gone)]

Checking in jar.mn;
/cvsroot/mozilla/browser/base/jar.mn,v  <--  jar.mn
new revision: 1.98; previous revision: 1.97
done
RCS file: /cvsroot/mozilla/browser/base/content/softwareUpdateOverlay.xul,v
done
Checking in content/softwareUpdateOverlay.xul;
/cvsroot/mozilla/browser/base/content/softwareUpdateOverlay.xul,v  <-- 
softwareUpdateOverlay.xul
initial revision: 1.1
done

Comment 13

[Asa Dotzler [:asa]]

Let's get this verified on the trunk today so we can consider it for the branch.

Comment 14

[Marcia Knous [:marcia]]

Verified using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1)
Gecko/20051019 Firefox/1.6a1. I no longer see the primary issue Dave is
reporting in the bug, which is the inability to use the menus while the update
dialog is in focus.

Dave points out that a number of the menu items are greyed out, which still
continues to be the case, but the relevant ones are active and able to be selected.

Comment 15

[Scott MacGregor]

Comment on attachment 199700 [details] [diff] [review]
patch [checked in]

approving based on marcia's verification.

Comment 16

[Asaf Romano (gone)]

Fixed on branch.

Comment 17

[Dave Miller [:justdave]]

This is back.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051019
(No IDN) Firefox/1.5

The difference I noticed: I got the "Update is available" prompt from an
automatic check.  All of my attempts to reproduce over the last week or two have
been initiating the update manually.

The Apple menu and the Firefox menu work, and that's it.  None of the other
menus even drop down when you click them.

Comment 18

[Dave Miller [:justdave]]

hmmm

/me notices the date this was checked in on the 1.8 branch and hopes it was a
fluke that it was actually working the last few days.

I'll ignore this unless it happens again tomorrow.

Comment 19

[Chase Phillips]

(In reply to comment #16)
> Fixed on branch.

The patch in this bug caused atlantia's Firefox build on the branch to go red
1-2 days ago and since.  Please see:
http://tinderbox.mozilla.org/showlog.cgi?log=Mozilla1.8/1129999320.20097.gz&fulltext=1

+++ making chrome
/builds/tinderbox/Fx-Mozilla1.8/Darwin_7.9.0_Depend/mozilla/browser/base  =>
../../dist/bin/chrome/browser.jar
error: file './content/softwareUpdateOverlay.xul' doesn't exist at
../../config/make-jars.pl line 443, <STDIN> line 47.
make[4]: *** [libs] Error 2
make[3]: *** [libs] Error 2
make[2]: *** [tier_99] Error 2
make[1]: *** [alldep] Error 2
make: *** [alldep] Error 2

I've run 'cvs update -r MOZILLA_1_8_BRANCH softwareUpdateOverlay.xul' by hand on
that system and prep'd it for a respin.  It should go green soon.

Mano, how did you add softwareUpdateOverlay.xul to the MOZILLA_1_8_BRANCH?  Did
you cvs add the file then tag -b it for the 1.8 branch?

Comment 20

[Chase Phillips]

(In reply to comment #16)
> Fixed on branch.

Also, please verify your patches don't break the build after landing them.  If
you'd checked (maybe you did) the Mozilla 1.8 Tinderbox you would have seen that
atlantia was hung.  Please let either myself or Coop know in those cases and we
will investigate the cause of the outage.  Thanks.

Comment 21

[Chase Phillips]

As I suspected the problem has recurred.  It may be related to how the file was
added to the 1.8 branch.

For future reference, I recommend that one first checkout a working copy from
the 1.8 branch, then cvs add the file from there.  Adding the file to the trunk
and tagging it on the branch may not be the best for our CVS history and may be
the cause of this issue.

Comment 22

[Chase Phillips]

(In reply to comment #21)
> As I suspected the problem has recurred.  It may be related to how the file was
> added to the 1.8 branch.

I don't have more time at the moment to continue looking into this.  Coop, can
you take a look now or later?  When I'm back online later I'll take another
look, too.

Comment 23

[Asaf Romano (gone)]

Sorry, I didn't notice the redness (dunno how, i did have the tb page open :-/ )

Comment 24

[Asaf Romano (gone)]

Actually, looking at the tinderbox page, atlantia was green for few cycles after
the checkin.

Comment 25

[Asaf Romano (gone)]

(In reply to comment #19)

> Mano, how did you add softwareUpdateOverlay.xul to the MOZILLA_1_8_BRANCH?  Did
> you cvs add the file then tag -b it for the 1.8 branch?

I don't have the the sh log atm; i didn't use -b IIRC.

Comment 26

[Chase Phillips]

(In reply to comment #25)
> (In reply to comment #19)
> 
> > Mano, how did you add softwareUpdateOverlay.xul to the MOZILLA_1_8_BRANCH?  Did
> > you cvs add the file then tag -b it for the 1.8 branch?
> 
> I don't have the the sh log atm; i didn't use -b IIRC.

You created a static tag on the file which isn't the same thing as adding it to the branch.  In the future, add new files on the branch by first checking out a copy of the source from the MOZILLA_1_8_BRANCH, applying the patch to that working directory, and then committing those files.  That will do the right thing re adding it to the branch.

Comment 27

[Chase Phillips]

Comment on attachment 199700 [details] [diff] [review]
patch [checked in]

Fixed on the 1.8 branch.

Checking in softwareUpdateOverlay.xul;
/cvsroot/mozilla/browser/base/content/softwareUpdateOverlay.xul,v  <--  softwareUpdateOverlay.xul
new revision: 1.1.4.2; previous revision: 1.1.4.1
done

Comment 28

[Asaf Romano (gone)]

Thanks Chase.