Closed Bug 1476605 Opened 2 years ago Closed 2 years ago

[Invalid Object] in console instead of Error object (caused by longString callstack)

Categories

(DevTools :: Console, defect, P1)

62 Branch
defect

Tracking

(firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 verified, firefox62 verified, firefox63 verified)

VERIFIED FIXED
Firefox 63
Tracking Status
firefox-esr52 --- unaffected
firefox-esr60 --- unaffected
firefox61 --- verified
firefox62 --- verified
firefox63 --- verified

People

(Reporter: aueelis, Assigned: nchevobbe)

References

Details

(Keywords: regression)

Attachments

(4 files)

Attached file error.txt
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180712042337

Steps to reproduce:

I'm developing a web application with Angular and observe some errors in the console.


Actual results:

Firefox just shows "Error [Invalid Object]".


Expected results:

It should show the content of the error, like it is happening in Chrome.

The output of Chrome's console is attached.
Hi, can you try to reproduce this issue using the latest version of Nightly you can find it here https://nightly.mozilla.org/, also can you attach the add-on to this bug report so we can try to reproduce this issue as well, Thanks.
Flags: needinfo?(aueelis)
Hi!

I can reproduce this issue in most recent nightly (2018-07-23). I can also reproduce this on a colleague's machine.

I can't attach an add-on, because there is no add-on related to this in use. If you are refering to Angular: That's a framework that you can find at https://angular.io/. Unfortunately, I can't share our application.

Is there anything else that I can do?
Flags: needinfo?(aueelis)
I found a way for you to reproduce it easily: I took the Angular tutorial app and added an infinite recursion in the main component.

You can find this modified application at:
https://stackblitz.com/edit/angular-3eqab4
Hi, I managed to reproduce this issue using the link from Comment 3 using the latest version of Firefox Nightly 63.0a1 (2018-07-26), Please note this issue might be a duplicate to Bug 1477951.
Status: UNCONFIRMED → NEW
Component: Untriaged → Console
Ever confirmed: true
Product: Firefox → DevTools
I can reproduce the issue with link from Comment 3. Thanks a lot aueelis, that will make fixing this bug much easier.
Assignee: nobody → nchevobbe
Status: NEW → ASSIGNED
Priority: -- → P1
So here's the faulty grip: 

```json
{
  "type": "object",
  "actor": "server1.conn1.child1/obj33",
  "class": "Error",
  "extensible": true,
  "frozen": false,
  "sealed": false,
  "ownPropertyLength": 6,
  "preview": {
    "kind": "Error",
    "name": "InternalError",
    "message": "too much recursion",
    "stack": {
      "type": "longString",
      "initial": "execute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:32:1\nexecute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:33:21\nexecute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:33:21\nexecute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:33:21\nexecute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:33:21\nexecute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:33:21\nexecute/AppComponent</AppComponent.prototype.doStuff@https://angular-3eqab4.stackblitz.io/tmp/appfiles/src/app/app.component.ts:33:21\nexecute/AppComponent</AppComponent.prototype.doStuff@https://an",
      "length": 17151,
      "actor": "server1.conn1.child1/longString27"
    },
    "fileName": "https://c.staticblitz.com/assets/engineblock-bc7b07e99ec5c6739c766b4898e4cff5acfddc137ccb7218377069c32731f1d0.js line 1 > eval",
    "lineNumber": 32,
    "columnNumber": 1
  }
}
```

It's failing here: https://github.com/devtools-html/debugger.html/blob/6d6b1366909cc921e72c2142a9945baed75dedc1/packages/devtools-reps/src/reps/error.js#L131 with "locationPars is null", because the location we are looking at was cut-off by the longstring stack to `https://an`.

Of course this wouldn't happen if we'd put https://github.com/devtools-html/debugger.html/blob/6d6b1366909cc921e72c2142a9945baed75dedc1/packages/devtools-reps/src/reps/error.js#L132 before L131 :/

I am going to fix this in github, add a test, and it'll be in Nightly in a few days.
release is affected, but esr is not.
It's probably worth uplifting the fix
Easy way to reproduce: 
1. Open the console
2. Evaluate the following: 

```js
{
x = new Error("hello")
x.stack = "s@http://exampl.com:1:1\n".repeat(1000)
x;
}
```

Expected result: 
I see a proper error with its stack

Actual result:
"Invalid object" is printed

---

You can see it's working with regular string stack by evaluating: 

```js
{
x = new Error("hello")
x.stack = "s@http://exampl.com:1:1\n".repeat(10)
x;
}
```
I confirm that the change from https://github.com/devtools-html/debugger.html/pull/6705 makes the issue go away in the comment 3 case.
Summary: [Invalid Object] in console → [Invalid Object] in console instead of Error object (caused by longString callstack)
Duplicate of this bug: 1477951
Comment on attachment 8995175 [details]
Bug 1476605 - Fix Error rep failure when stacktrace is a longString; .

https://reviewboard.mozilla.org/r/259656/#review266956

Very nice that you added an extra test to make sure this doesn't happen again! I think this looks good, except for that maybe leftover console.log - I opened an issue for it, please check it out. Otherwise r+ from me :)

::: devtools/client/shared/components/reps/reps.js:1948
(Diff revision 2)
>  
>    const isStacktraceALongString = isLongString(preview.stack);
>    const stackString = isStacktraceALongString ? preview.stack.initial : preview.stack;
> -
> +console.log("stackString", stackString)
>    stackString.split("\n").forEach((frame, index) => {
> +    console.log("frame", frame)

Is that console.log intentional or a leftover?
Attachment #8995175 - Flags: review?(spenades) → review+
> Is that console.log intentional or a leftover?

Definitely leftovers. I'll delete them before landing. Thanks sole !
Pushed by nchevobbe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/98a2048f6d50
Fix Error rep failure when stacktrace is a longString; r=sole.
https://hg.mozilla.org/mozilla-central/rev/98a2048f6d50
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 63
Comment on attachment 8995175 [details]
Bug 1476605 - Fix Error rep failure when stacktrace is a longString; .

Approval Request Comment
[Feature/Bug causing the regression]: Bug 1449165 (parsing error.stack to print it in a nicer way)
[User impact if declined]: Can't see errors if they have a very long stacktrace (> 10000 chars)
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: Yes
STR: 

1. Open the console
2. Evaluate the following: 

```js
{
x = new Error("hello")
x.stack = "s@http://exampl.com:1:1\n".repeat(1000)
x;
}
```
3. Make sure you can see an error object, and not "Invalid Object"

[List of other uplifts needed for the feature/fix]: -
[Is the change risky?]: No
[Why is the change risky/not risky?]: Test added + one-liner change (guarding a property access)
[String changes made/needed]: -

---

Not sure if it applies cleanly on Beta and release though, since it's a bundle
Attachment #8995175 - Flags: approval-mozilla-release?
Attachment #8995175 - Flags: approval-mozilla-beta?
Hi, I managed to reproduce this issue in Firefox Nightly 63.0a1 (2018-07-26) but I can no longer reproduce this issue in Nightly 63.0a1 (2018-07-29).
I will mark it accordingly, also I will add the flags for 61 and 61 as they are both affected.
Status: RESOLVED → VERIFIED
Comment on attachment 8995175 [details]
Bug 1476605 - Fix Error rep failure when stacktrace is a longString; .

Fix was verified on Nightly, low-risk, Beta62+
Attachment #8995175 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Hi, I reproduced this issue in the older versions of Beta as well but I can no longer reproduce this issue in Firefox Beta 62.0b14 (64-bit), I will mark this issue accordingly.
Flags: qe-verify+
Comment on attachment 8995175 [details]
Bug 1476605 - Fix Error rep failure when stacktrace is a longString; .

This patch doesn't graft cleanly to release. Please attach a rebased patch and re-request approval on it if you want this to be considered for 61.0.2.
Flags: needinfo?(nchevobbe)
Attachment #8995175 - Flags: approval-mozilla-release? → approval-mozilla-release-
Flags: in-testsuite+
Approval Request Comment
[Feature/Bug causing the regression]: Bug 1449165 (parsing error.stack to print it in a nicer way)
[User impact if declined]: Can't see errors if they have a very long stacktrace (> 10000 chars)
[Is this code covered by automated tests?]: Yes
[Has the fix been verified in Nightly?]: Yes
[Needs manual test from QE? If yes, steps to reproduce]: Yes
STR: 

1. Open the console
2. Evaluate the following: 

```js
{
x = new Error("hello")
x.stack = "s@http://exampl.com:1:1\n".repeat(1000)
x;
}
```
3. Make sure you can see an error object, and not "Invalid Object"

[List of other uplifts needed for the feature/fix]: -
[Is the change risky?]: No
[Why is the change risky/not risky?]: Test added + one-liner change (guarding a property access)
[String changes made/needed]: -

---

I applied this patch on the release branch and pushed to TRY https://treeherder.mozilla.org/#/jobs?repo=try&revision=e54ebe4c07c8fa26366eaccc859e666e3bdbc184 which seems to indicate everything is good.
Flags: needinfo?(nchevobbe)
Attachment #8998229 - Flags: approval-mozilla-release?
Comment on attachment 8998229 [details] [diff] [review]
1476605_release.patch

One-liner fix with an automated test, verified on Nightly and Beta. Approved for 61.0.2.
Attachment #8998229 - Flags: approval-mozilla-release? → approval-mozilla-release+
Flags: qe-verify+
I managed to reproduce the initial issue using the indications provided in comment 0 and comment 3. I also can confirm that 61.0.2 build1 (20180807170231) is fixed. Marking it accordingly.
Flags: qe-verify+
I'm seeing the message in my console on Developer Edition 64.0b9, x64 Win10. The steps to reproduce in comment 24 don't any more, so it's something different.
(In reply to Scott Martin from comment #28)
> I'm seeing the message in my console on Developer Edition 64.0b9, x64 Win10.
> The steps to reproduce in comment 24 don't any more, so it's something
> different.

Hello Scott, I'm sorry this is still happening.

This might be another object causing this.
Would you have an online test case I can test to see the issue ?
If not, could you get to the console.log/error triggering this ? (if that's an error, you can enable the "break on exception" toggle in the debugger to check the error object.)
Flags: needinfo?(scott)
Hi Nicolas. Unfortunately it was only occurring during testing on a local file, and now it's not! Which is kind of interesting. If it comes up again I'll try to pin it down, but the best info I can provide until then was that it came immediately after having used console.info to display a fetch response object.
Flags: needinfo?(scott)
Erf :( 
So you were console.info(response) ? or the promise ? Do you remember if it had anything special ?
Flags: needinfo?(scott)
Totally vanilla stuff...

return fetch(url, req)
    .then( res => {
        if (res.ok) {
            if (MODE == "dev") {
                console.info(req);
                console.info(res); // occurred after this output
            }
        } else {
            console.error(res.statusText);
        }

        return res;
    })
    .catch( error => {
        console.error(err);
    });


It's not happened again since that one time. Sorry that I can't be more helpful!
Flags: needinfo?(scott)
thanks for helping anyway :) 
So there's probably something with the response object, maybe in the header or something 🤔 
I'll try to reproduce that, and if I do, I'll create a bug for it and ping you there (if that's okay :) )
I encountered the same [Invalid object] error as well, and in my code I can reproduce it every single time.

Bit of context: I'm fetching comments from a Reddit thread and trying to process them. I've stripped the code of any irrelevant parts.

Possibly relevant: the snoowrap library which I'm using makes utilizes  https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy.

I'm using Firefox 63.0.3, so that version should have the patch.
Note that you should probably run the attachment on some local server, because if you just run it from a file it breaks because Reddit doesn't get an origin header.
(In reply to gbugzilla from comment #34)
> Created attachment 9029437 [details]
> Code wheref [Invalid object] occurrs
> 
> I encountered the same [Invalid object] error as well, and in my code I can
> reproduce it every single time.
> 
> Bit of context: I'm fetching comments from a Reddit thread and trying to
> process them. I've stripped the code of any irrelevant parts.
> 
> Possibly relevant: the snoowrap library which I'm using makes utilizes 
> https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/
> Proxy.
> 
> I'm using Firefox 63.0.3, so that version should have the patch.

Sadly I can't reproduce :(

Would it be possible to stringify the JSON response that causesd the "Invalid Object" and copy it here so we can check if it's that?
You need to log in before you can comment on or make changes to this bug.