1678243 - Console error: XDR encoding failure from Nov 13th

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P1)

Description

[JB Manasa]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.198 Safari/537.36

Steps to reproduce:

1.Go to firefox version Firefox 83.0
2. Login to facebook account using credentials [e-mail]/t3st@123
3. Open our game https://apps.facebook.com/mesmogames/
4. Open console logs before opening game.

Actual results:

In console provided error is seen XDR encoding failure in file https://cdn.trackjs.com/agent/v3/latest/t.js 13 : 288. Because of this, app is not loading for certain players in firefox.
Note: This issue is seen only in firefox and in particular versions Firefox 83.0 and Firefox 80.0. In no other browser issue is seen.

Expected results:

This console error should not been seen and game should have loaded properly

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[JB Manasa]

This component means are you mentioning about https://cdn.trackjs.com/agent/v3/latest/t.js ? If so, we are using this same lib from last two years now and suddenly only in firefox this error is seen

Comment 3

[Travis Thelen]

We are seeing a similar error in our application. Randomly, pages generate "XDR encoding failure" exceptions. No additional details in error and no break when launched in the debug tools

Comment 4

[JB Manasa]

Any update on the issue! This looks like Xdomainrequest object not supported issue but many of the nodemodules like axios and others are using it.

Comment 5

[rafael.korbas]

We confirm having a similar problem on our website (https://adalite.io). FF 83.0 users are getting intermittent "XDR encoding failure" result right at after loading the page. Interestingly, it seems to happen only when caching is enabled.

Comment 6

[Travis Thelen]

After more testing, we also see the issue only when caching is enabled - as @rafael.korbas mentions above. With caching disabled in the debug tools, the error never happens.

Comment 7

[Travis Thelen]

see file
mozilla-central/js/src/vm/JSScript.cpp

The JS_ReportErrorASCII was recently added ... the prior code just returned false

if (!hasEncoder()) {
JS_ReportErrorASCII(cx, "XDR encoding failure");
return false;
}

source code blame:
Bug 1662273 - Use stencil XDR in incremental encoding and off-thread single script decoding. r=tcampbell
Tooru Fujisawa <[e-mail]>, Mon, 28 Sep 2020 17:14:34 +0000

Comment 8

[André Bargull [:anba]]

Hi Arai, could this issue be related to the changes from bug 1662273?

Comment 9

[Tooru Fujisawa [:arai]]

Thank you for reporting.
I'll take a look immediately.

Comment 10

[Tooru Fujisawa [:arai]]

Attachment: Bug 1678243 - Clear exception set by JS::FinishIncrementalEncoding. r?tcampbell!

Comment 11

[Tooru Fujisawa [:arai]]

The issue was the following:

1. when a script is loaded 4 times or more, we try to cache bytecode for the script
2. bytecode cache doesn't support asm.js, and if a script contains asm.js, we abort bytecode cache
3. in term of API design, if encoding of bytecode cache is aborted for any reason, it should have reported error, so we fixed the API to report error on such case
4. on the other hand, in the consumer side of the API, if any error or abort happens, it just give up generating bytecode cache, and fallback to normal load for next time, so the consumer is not interested into the error
5. the consumer didn't handle error case properly and it was working before firefox 83 just because we didn't report error message for aborted case

so, fixed the consumer to explicitly clear and ignore the error.

Comment 12

[Tooru Fujisawa [:arai]]

[Tracking Requested - why for this release]: website uses asm.js may stop working after loading 4 times

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/610b0b709201
Clear exception set by JS::FinishIncrementalEncoding. r=tcampbell

Comment 14

[Tooru Fujisawa [:arai]]

Comment on attachment 9189868 [details]
Bug 1678243 - Clear exception set by JS::FinishIncrementalEncoding. r?tcampbell!

Beta/Release Uplift Approval Request

• User impact if declined: Website uses asm.js may stop working after loading 4 times,
  especially if the website is monitoring "onerror" event, the unexpected/unnecessary error is reported to the handler.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): basically this changes the behavior back to before the regression (don't report unexpected/unnecessary error), but with clearer API design.
• String changes made/needed:

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/610b0b709201

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9189868 [details]
Bug 1678243 - Clear exception set by JS::FinishIncrementalEncoding. r?tcampbell!

Approved for 84.0b7.

Comment 17

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/698d9f16b748

Comment 18

[Andrei Purice]

Hey Jb,
I tried reproducing this issue on older and your recommended builds but could not reproduce the issue. After the first 5 tries the password for the account was changed I believe because I could not login anymore with it and used a personal test account.
Can you check if this issue is fixed on the latest beta 84.0b7 and nightly 85.0a1 (2020-12-02) builds and leave a comment for us to know ?
You can download the builds from here : https://www.mozilla.org/en-US/firefox/channel/desktop/

Comment 19

[JB Manasa]

Hi Anderi, Our qa team is trying to check the issue on latest beta versions you have provided. Since the issue is not consistent we are not able to come into conclusion on this.

Comment 20

[JB Manasa]

Hi Andrei, Our qa team tried on your beta versions provided and couldn't reproduce the issue.

Comment 21

[Tooru Fujisawa [:arai]]

Thank you for checking!

Comment 22

[Brindusa Tot, Desktop QA]

Considering that we were not able to reproduce the initial issue, and based on comment 20, marking this bug verified on Beta.
Removing the qe-verify+ flag, but please add it back if more verification is needed.