In PR #18260 we enabled dumpio: true for Puppeteer. This option forwards the browser logs to Node's log stream so that we can see any warnings/errors that are logged in e.g. the web console. This surfaced a few interesting issues that we should fix before we enable that further due to the spammy nature of said logs.
This might very well be intended though, and this is the part I don't know. I'm also not sure why there is a dedicated testing path in this code, because if we fall through we'll always get here in testing mode too. @Snuffleupagus Do you perhaps have ideas for this, since you probably know this code a lot better than I do?
In PR #18260 we enabled
dumpio: truefor Puppeteer. This option forwards the browser logs to Node's log stream so that we can see any warnings/errors that are logged in e.g. the web console. This surfaced a few interesting issues that we should fix before we enable that further due to the spammy nature of said logs.This issue tracks the following often repeated log from http://54.241.84.105:8877/34fcd127eefeaf9/output.txt:
I have tracked the problem down to https://github.com/mozilla/pdf.js/blob/06800cd966111f7262d3334dfb68c3765bc92740/web/genericl10n.js#L79 being triggered, which in turn triggers https://github.com/mozilla/pdf.js/blob/06800cd966111f7262d3334dfb68c3765bc92740/web/genericl10n.js#L110-L112 and because we're in testing mode the exception is thrown.
Both code paths were introduced in https://github.com/mozilla/pdf.js/commit/97c2ce9da02dfc3ee3a563342e48540c07c18a6f but unfortunately I don't know enough about the L10n bundle handling to be able to tell for sure what the issue is. However, in debugging this I found that we in fact have a valid bundle for
en-usjust before at https://github.com/mozilla/pdf.js/blob/06800cd966111f7262d3334dfb68c3765bc92740/web/genericl10n.js#L76 which made me wonder why we also try to create a fallback bundle for this language, and thought: are we perhaps missing acontinueafter theyieldhere? If I look at the situation before the patch, see https://github.com/mozilla/pdf.js/commit/97c2ce9da02dfc3ee3a563342e48540c07c18a6f#diff-28e788fc43e67c197d60ffb3054ffb599f083341963c64d156e7a87a0ced98ceR78, we would always continue implicitly after theyield, but now it basically falls through to the fallback bundle creation.This might very well be intended though, and this is the part I don't know. I'm also not sure why there is a dedicated testing path in this code, because if we fall through we'll always get here in testing mode too. @Snuffleupagus Do you perhaps have ideas for this, since you probably know this code a lot better than I do?