RDFItemUpdater shouldn't check for updates for items with pending optypes

RESOLVED FIXED in mozilla1.9alpha8

Status

()

RESOLVED FIXED
12 years ago
10 years ago

People

(Reporter: mossop, Assigned: mossop)

Tracking

unspecified
mozilla1.9alpha8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

12 years ago
 
(Assignee)

Comment 1

12 years ago
Created attachment 273941 [details] [diff] [review]
patch rev 1
Attachment #273941 - Flags: review?(robert.bugzilla)
Attachment #273941 - Flags: review?(robert.bugzilla) → review+
Summary: RDFItemUpdater shouldnt check for updates for items with pending optypes → RDFItemUpdater shouldn't check for updates for items with pending optypes
(Assignee)

Comment 2

12 years ago
Comment on attachment 273941 [details] [diff] [review]
patch rev 1

Seeking approval for this simple patch which stops us attempting to find updates for add-ons that already have new versions waiting to be installed.
Attachment #273941 - Flags: approval1.9?
(In reply to comment #2)
> (From update of attachment 273941 [details] [diff] [review])
> Seeking approval for this simple patch which stops us attempting to find
> updates for add-ons that already have new versions waiting to be installed.
I thought that case was already handled previously. Just for my own clarity, doesn't this just change it so we don't check for updates in the background for extensions that have a pending disable / enable operation?

Drivers, this is a low risk patch to make the background update check behave the same as the ui's update check.
(Assignee)

Comment 4

12 years ago
(In reply to comment #3)
> I thought that case was already handled previously. Just for my own clarity,
> doesn't this just change it so we don't check for updates in the background for
> extensions that have a pending disable / enable operation?

You're right I didn't read close enough, it changes the restriction to stop check for add-ons with any pending operation.
Dave, as a side note... it is my understanding that for M8 driver approval is required for gecko 1.9 changes and is not required for toolkit or browser. I've asked for verification that this is truly the case.
Comment on attachment 273941 [details] [diff] [review]
patch rev 1

Per http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/3e988240291a846b/02cda78d0c0b7707#02cda78d0c0b7707

On the browser/toolkit the tree is still considered open, as the feature
freeze for the front end is targeted at M8.

Clearing a and go ahead and check this in. Thanks!
Attachment #273941 - Flags: approval1.9?
(Assignee)

Comment 7

12 years ago
Checking in toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--  nsExtensionManager.js.in
new revision: 1.232; previous revision: 1.231
done
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
(Assignee)

Updated

11 years ago
Target Milestone: --- → Firefox 3 M8
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.