Closed
Bug 595092
Opened 15 years ago
Closed 15 years ago
Attempting to access the extensions datasource too early in startup will fail and leave the datasource inaccessible for the entire session
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status2.0 | --- | unaffected |
blocking1.9.2 | --- | - |
status1.9.2 | --- | .11-fixed |
People
(Reporter: mossop, Assigned: mossop)
Details
(Whiteboard: [qa-examined-192][qa-needs-str])
Attachments
(1 file)
5.42 KB,
patch
|
robert.strong.bugs
:
review+
dveditz
:
approval1.9.2.11+
|
Details | Diff | Splinter Review |
If _ensureDS is called before ProfD is available we end up defining _ds but it has no datasource loaded in it so all attempts to use it will throw exceptions.
We can protect against this quite easily and we should as if extensions do this it currently leaves the extension manager, blocklist service and app updates broken.
Assignee | ||
Updated•15 years ago
|
Assignee: nobody → dtownsend
blocking1.9.2: --- → ?
Assignee | ||
Comment 1•15 years ago
|
||
This keeps the add-ons manager in a sane state if the datasource is accessed before ProfD is available. Accessing the datasource at that point will still throw but we no longer cache the bad datasource we get and allow it to be recreated at a future time.
The test was a bit tricky, putting it into the same directory as the others would make it impossible to test as a profile directory is always defined there, and I had to define ProfDS since that is always available by the time the extension manager can be accessed.
Attachment #474200 -
Flags: review?(robert.bugzilla)
Updated•15 years ago
|
status2.0:
--- → unaffected
![]() |
||
Updated•15 years ago
|
Attachment #474200 -
Flags: review?(robert.bugzilla) → review+
Assignee | ||
Comment 2•15 years ago
|
||
Comment on attachment 474200 [details] [diff] [review]
patch rev 1
This patch is a protective measure to help us be resilient in the face of extensions doing weird things. In introduces no behavioral change for the normal case and includes an automated test to verify that it fixes the breakage that we'd normally see here.
Attachment #474200 -
Flags: approval1.9.2.10?
Comment 3•15 years ago
|
||
Is a backport to 1.9.1 needed, possible, or even doable before its EOL?
Assignee | ||
Comment 4•15 years ago
|
||
The patch probably applies as-is, not sure how worth it it is at this point though.
Comment 5•15 years ago
|
||
There's some complaining about the Personas Plus 1.6 mess under Firefox 3.5.x in bug 590978 (which was just set to blocking both 1.9.2 and 1.9.1), so if this is doable on both branches without too much trouble then it's probably worth it.
Assignee | ||
Comment 6•15 years ago
|
||
(In reply to comment #5)
> There's some complaining about the Personas Plus 1.6 mess under Firefox 3.5.x
> in bug 590978 (which was just set to blocking both 1.9.2 and 1.9.1), so if this
> is doable on both branches without too much trouble then it's probably worth
> it.
The personas extension doesn't override the extension manager in 3.5 so in that particular case 3.5 is unaffected.
Comment 7•15 years ago
|
||
(In reply to comment #6)
> (In reply to comment #5)
> > There's some complaining about the Personas Plus 1.6 mess under Firefox 3.5.x
> > in bug 590978 (which was just set to blocking both 1.9.2 and 1.9.1), so if this
> > is doable on both branches without too much trouble then it's probably worth
> > it.
>
> The personas extension doesn't override the extension manager in 3.5 so in that
> particular case 3.5 is unaffected.
Then I guess the blocking1.9.1.13+ in bug 590978 is unwarranted, which was why I asked here.
If this patch won't hurt but might help, and requires no extra effort to backport, then I'd suggest landing it there just in case. If there's a noteworthy risk, then nevermind.
Updated•15 years ago
|
blocking1.9.2: ? → -
status1.9.2:
--- → wanted
Comment 8•15 years ago
|
||
Comment on attachment 474200 [details] [diff] [review]
patch rev 1
Approved for 1.9.2.11, a=dveditz for release-drivers
Attachment #474200 -
Flags: approval1.9.2.11? → approval1.9.2.11+
Assignee | ||
Comment 9•15 years ago
|
||
Landed on the branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/a47ecaf1f779
Status: NEW → RESOLVED
Closed: 15 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Comment 10•15 years ago
|
||
How do we test this fix in 1.9.2? Is there a way to reliably trigger the original issue?
Whiteboard: [qa-examined-192] [qa-needs-str]
Comment 11•14 years ago
|
||
(In reply to comment #10)
> How do we test this fix in 1.9.2? Is there a way to reliably trigger the
> original issue?
Dave, any chance to get it verified manually?
Whiteboard: [qa-examined-192] [qa-needs-str] → [qa-examined-192][qa-needs-str]
Assignee | ||
Comment 12•14 years ago
|
||
(In reply to comment #11)
> (In reply to comment #10)
> > How do we test this fix in 1.9.2? Is there a way to reliably trigger the
> > original issue?
>
> Dave, any chance to get it verified manually?
The most straightforward way would probably be to try to reproduce bug 590608
You need to log in
before you can comment on or make changes to this bug.
Description
•