575296 - Firefox Update should show no options in the context menu (e.g. right click)

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect)

Description

[Luke Burrows]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6

Since Firefox Update cannot be run manually, when the icon is right clicked it should do nothing.


Reproducible: Always

Steps to Reproduce:
1.Download the update if it's available.
2.Restart Firefox to install the update.
3.Right click on the Firefox Update icon before it disappears. 
Actual Results:  
It displays "Pin to Taskbar", "Firefox Software Updater" and "Close Window".


Expected Results:  
It should do nothing.

Comment 1

[Luke Burrows]

This bug will also block the release of Firefox 4 Beta 2 and Firefox 3.6.8 and will
not affect Firefox 3.5 as it's approaching the End of Life scheduled for August
2010 and Firefox 3 as it is no longer supported.

Comment 2

[Luke Burrows]

If Firefox for mobile uses 1.9.2.8 for 1.1, then it will also be reserved for the
1.9.2.9 branch for Firefox 3.6.

Comment 3

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

It shouldn't show those but I highly doubt this will cause any problems for the vast majority of users especially since it has been this way for quite some time with no bug reports so adjusting priority, etc. accordingly.

Comment 4

[Luke Burrows]

I believe the status should be New.

Comment 5

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

Sure but it is by no means a blocker or P1

Comment 6

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

note to self: when fixing this it would be a good thing to fix bug 575266 at the same time.

Comment 7

[Luke Burrows]

Firefox 3.6.8 and Firefox 4 Beta 2 can't also be shipped unless it is WONTFIX,
FIXED
or INVALID, because "Pin to Taskbar, "Firefox Software Updater" and "Close
Window" can't all be used, because there is no close button on the Firefox
Update box that says "Firefox is installing your updates and will start in a
few moments."

Comment 8

[Luke Burrows]

Maybe fixing bug 575266 in time for Firefox 4 Beta 2 and Firefox 3.6.8 at the same time would be a good idea.

Comment 9

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

Luke, do not change the status of this bug again... this is your first warning.

It can be shipped with this bug and we have shipped with this bug in previous versions of Firefox. See Ted's comment in bug 575266 comment #6.

Comment 10

[Luke Burrows]

Sorry about that, but anyways I think it should happen as Normal instead of a blocker.

Comment 11

[Luke Burrows]

Is that INVALID?

Comment 12

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

Second warning.

Read the following... I own the app update module.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Comment 13

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

It is not invalid and it is not a blocker.

Comment 14

[Luke Burrows]

Is that VALID?

Comment 15

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

No, now stop messing with the bug fields. This is your 3rd warning. Leave them alone!

Comment 16

[Luke Burrows]

Bug 575266 and Bug 575296 needs to be fixed now!

Comment 17

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

Gerv, I've asked Luke several times to leave the fields in this bug alone and he has reqeatedly ignored the request even after pointing. Can you help him out with understanding what is acceptable and what is not? Thanks

Comment 18

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

(In reply to comment #17)
> Gerv, I've asked Luke several times to leave the fields in this bug alone and
> he has reqeatedly ignored the request even after pointing
him to the etiquette guidelines

Comment 19

[Matthias Versen [:Matti]]

Luke: 
https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance
This bug doesn't block the development=not a blocker. This is either minor or trivial. What you think about importance of this bug doesn't matter and the priority field is a private field for the developer who wants to fix the bug, not for you. Attach a patch if you want to get this fixed faster.

Comment 20

[Gervase Markham [:gerv]]

rs: sorry for the slow response; looks like mconnor's sorted the problem.

Gerv

Comment 21

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

Attachment: patch rev1

Comment 22

[Jim Mathies [:jimm]]

Comment on attachment 510224 [details] [diff] [review]
patch rev1

RegSetValueEx -> RegSetValueExW

r+ with that change.

Can we remove this on uninstall?

Comment 23

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

(In reply to comment #22)
> Comment on attachment 510224 [details] [diff] [review]
> patch rev1
> 
> RegSetValueEx -> RegSetValueExW
> 
> r+ with that change.
> 
> Can we remove this on uninstall?
These are removed on OS restart since the key is created / opened with REG_OPTION_VOLATILE.

Comment 24

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

Attachment: patch - updated to comments

Carrying forward r+

Comment 25

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

Pushed to mozilla-central
http://hg.mozilla.org/mozilla-central/rev/34a452a19db1

I personally don't think it is all that valuable (or easy compared to bug 575266) to have a litmus test for this but I'll leave that up to QA to decide.

Comment 26

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

This is such a minor issue that I don't see any value in having a litmus test