the checkin for bug 287107 broke Forumzilla

RESOLVED FIXED in mozilla1.8beta2

Status

()

defect
P1
major
RESOLVED FIXED
14 years ago
8 years ago

People

(Reporter: myk, Assigned: brendan)

Tracking

Trunk
mozilla1.8beta2
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

Reporter

Description

14 years ago
Since the fix for bug 287107 was checked in, the Forumzilla extension for
Thunderbird dies with the following error:

JavaScript error: , line 0: uncaught exception: [Exception... "Component
returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)
[nsIJSCID.getService]"  nsresult: "0x80570016
(NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame ::
chrome://forumzilla/content/forumzilla.js :: onLoad :: line 35"  data: no]

Lines 32-35 of forumzilla.js:

    feedService = 
      Components
        .classes["@forumzilla.mozdev.org/feed/feedservice;1"]
          .getService(Components.interfaces.nsIFeedService);

The feed service is a JavaScript XPCOM component that comes with Forumzilla.

Reinstalling Forumzilla doesn't solve the problem, nor does installing into a
fresh profile.  The fix for bug 287490 doesn't have any effect either, but
everything works fine if I back out the fix for bug 287107.
Assignee

Comment 1

14 years ago
I never saw bugmail from being cc'd on this bug.  Hrm.  Anyone see mail log
traces saying why?

Should this bug be WFM now, or FIXED?

/be

Comment 2

14 years ago
This is windows as well as Linux.

I don't think this is fixed at all -- unless something changed in the last
couple of hours and bonsai doesn't show anything.
OS: Linux → All
Reporter

Comment 3

14 years ago
> I never saw bugmail from being cc'd on this bug.  Hrm.  Anyone see mail log
> traces saying why?

All mozilla.org mail was bouncing for two hours today around the time I filed
this bug after dbaron accidentally horked the aliases database.  That's probably
why you didn't receive mail about it (I didn't either).

> Should this bug be WFM now, or FIXED?

Neither unless something has changed since this afternoon, when I pulled and
built again to confirm the bug on the tip.  Note that bug 287490, the other
regression from bug 287107 (which this bug may just be a dupe of), has since
been reopened, as two users report that the patch on that bug didn't fix the
problem for them.
Assignee

Comment 4

14 years ago
Myk, can you breakpoint
http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcjsid.cpp#900 and
see why that's being hit?

/be
Reporter

Comment 5

14 years ago
> Myk, can you breakpoint
> http://lxr.mozilla.org/mozilla/source/js/src/xpconnect/src/xpcjsid.cpp#900 and
> see why that's being hit?

rv=0x80004002 and srvc is a null pointer at line 900 when the app tries to load
the feed service.
Assignee

Comment 6

14 years ago
Posted patch fix? (obsolete) — Splinter Review
Assignee

Comment 7

14 years ago
Posted patch fix?Splinter Review
Assignee: dbradley → brendan
Attachment #178775 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Assignee

Comment 8

14 years ago
Working with myk over IRC, finding that one thing that might be adding noise is
a lack of nsISupports handling in JS-scripted QueryInterface impls.  Myk fixed
his to handle nsISupports and that moved the symptom.  Could download code have
a similar lack in one of its scripted QI impls?

/be
Severity: normal → critical
Priority: -- → P1
Target Milestone: --- → mozilla1.8beta2
Assignee

Comment 9

14 years ago
Fooey.  I backed out.  Something's not right in a bunch of places in our JS QI
impls, which return null after setting Components.returnCode ineffectually (due
to bug 287107).  My fix for bug 287107 makes these QIs truly fail with
NS_NOINTERFACE yet not throw, and that leaves callers unhappy.

Keeping bug open to investigate more.

/be
Severity: critical → major
Assignee

Comment 10

14 years ago
<brendan> k, here's what happened
<brendan> rev 1.73 of xpcwrappedjsclass.cpp regressed things so a JS method
couldn't set Components.returnCode, and succeed (not throw or error out), yet
have the returnCode propagate back to the XPConnected caller
<brendan> that means these QueryInterface impls in JS, such as yours, are
wasting their time setting Components.returnCode without also throwing
(failing)
<brendan> cuz it's never fetched via GetPendingResult in any
xpconnect/src/*.cpp (grep yourself) on a success path
<brendan> my fix for 287107 made these returnCode statements do what they used
to
<brendan> and that showed up bugs
<brendan> your QI didn't handle nsISupports
<brendan> and maybe download mgr bugs of that kind
<brendan> i'll patch privately and debug more, later
<myk> i'll do the same and see if i can fix any bugs in my components
<brendan> i'll put the private patch up and then crash -- it's tricky
Hardware: PC → All
Assignee

Comment 11

14 years ago
Technically fixed, again.  Hope not to reopen if the private patch shakes out
all the missing QI cases.

/be
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.