[Mainsite] Blank page when using Pale Moon [Fixed]

[Mima-sama]

Hi, I'm trying to access a doujin: https://mangadex.org/title/1fd60886...been-an-incident-so-time-for-some-new-clothes

But it's only returning a blank page for me on Pale Moon, the browser I mainly use. When I looked at the browser's error console, it tells me that the site requires dynamic module import; luckily I regularly build from the browser's master branch (since I'm involved with Pale Moon's development), and the latest trunk just recently included an implementation of the said feature (which we track in UXP Issue #1691). I've enabled the feature as instructed by the pull request, and while the error about dynamic module import went away, it still returns a blank page. Looking at the error console again, it has given two different errors this time:

TypeError: o is undefined                                     entry.45e322df.js:1:14711
Stack trace:
setup@https://mangadex.org/_nuxt/entry.45e322df.js:75:175384
pn@https://mangadex.org/_nuxt/entry.45e322df.js:1:14205
D5@https://mangadex.org/_nuxt/entry.45e322df.js:1:64046
zm@https://mangadex.org/_nuxt/entry.45e322df.js:1:63831
S@https://mangadex.org/_nuxt/entry.45e322df.js:1:51341
D@https://mangadex.org/_nuxt/entry.45e322df.js:1:51234
p@https://mangadex.org/_nuxt/entry.45e322df.js:1:48108
Jw@https://mangadex.org/_nuxt/entry.45e322df.js:1:19604
process@https://mangadex.org/_nuxt/entry.45e322df.js:1:19350
p@https://mangadex.org/_nuxt/entry.45e322df.js:1:48146
z@https://mangadex.org/_nuxt/entry.45e322df.js:1:52314
run@https://mangadex.org/_nuxt/entry.45e322df.js:1:5082
G/F.update@https://mangadex.org/_nuxt/entry.45e322df.js:1:52583
G@https://mangadex.org/_nuxt/entry.45e322df.js:1:52609
S@https://mangadex.org/_nuxt/entry.45e322df.js:1:51437
D@https://mangadex.org/_nuxt/entry.45e322df.js:1:51234
p@https://mangadex.org/_nuxt/entry.45e322df.js:1:48108
le@https://mangadex.org/_nuxt/entry.45e322df.js:1:56330
mount@https://mangadex.org/_nuxt/entry.45e322df.js:1:43641
u2/t.mount@https://mangadex.org/_nuxt/entry.45e322df.js:1:83589
Mg@https://mangadex.org/_nuxt/entry.45e322df.js:75:177569

Timestamp: 4 May 2023 22:27:51
Error: XML Parsing Error: no root element found
Location: https://api.mangadex.org/auth/refresh
Line Number 1, Column 1:
Source File: https://api.mangadex.org/auth/refresh
Line: 1

Unfortunately I have no idea what is wrong, as the JavaScript is minified as hell. Without specifics on what is causing the issue, we won't be able to fix up what needs to be fixed up in our JavaScript engine, so as one of the browser's developers, please either provide a working fallback for browsers not supporting dynamic module import (this would be best IMO in the spirit of the open web) or tell us what JS cruft needs to be implemented so it can be triaged by us in our issue tracker. Thanks!

 

[Penthero]

Looks like the browser isn’t supported.

 

[tristan9]

please either provide a working fallback for browsers not supporting dynamic module import

As moon himself noted in the thread, this is a tech change by Nuxt themselves, not us; we can't really provide a fallback ourselves

setup@https://mangadex.org/_nuxt/entry.45e322df.js:75:175384

Would be good to see the minified JS on which things are failing here; even if minified it might give us a hint as to what's wrong exactly? I don't believe our frontend uses any particularly experimental JS features besides function-style import, since we do need to support more than just latest-chromium & friends (notably older Safari, where we currently are compatible with iOS 13 or so, tends to not adopt newer features particularly quickly)

Error: XML Parsing Error: no root element found Location: https://api.mangadex.org/auth/refresh

That's a bug in Palemoon and unrelated to JS; we return a 204 on that endpoint most of the time, so there's no content to parse at all (hence that XML parsing error); see the response headers here for that request:

Specifically:

• content-length is set to 0, so there cannot be content that PM seems to expect nonetheless
• content-type is also absent, so it's not us suggesting anything
• x-content-type-options is set to nosniff, so PM really ought to not try to do anything with the response content

 

[tristan9]

Something we could consider is trying this out ourselves on a local non-minified version of the site in case it's relatively easy for us to fix. Let us know once a release with that patch is in (or if there's officially sanctioned trunk binaries somewhere we could use; trying to avoid figuring out the build system of a project as complex as a whole browser...)

 

[Mima-sama]

As moon himself noted in the thread, this is a tech change by Nuxt themselves, not us; we can't really provide a fallback ourselves

I understand. I think 99% of the web compat issues we're getting is caused by a web framework updating itself to require new shiny features, even if those features aren't necessary (or also often, doesn't make sense at all) for the normal operation of their clients. I really wish they stop doing that, or at least provide fallbacks (which isn't ideal because polyfills are so slow, but it's better than nothing)...

Would be good to see the minified JS on which things are failing here

The offending JS can be found at https://mangadex.org/_nuxt/entry.45e322df.js (I've made a backup at https://bhh.sh/6rh just in case Nuxt updates the code). I don't think it's a good idea to paste the whole thing here, as it's literally a megabyte full of just minified JavaScript code...

I don't believe our frontend uses any particularly experimental JS features besides function-style import

According to a quick skim by one of our developers, it seems your framework is also requiring BigInt (tracked in UXP Issue #1240, note the lack of progress there), which totally doesn't make sense to require for websites like yours... I can understand dynamic module import being a pretty useful syntactic sugar compared to the previous, established imports from ES6, but BigInt... It's only useful for cryptography (and even in that niche there are alternatives which we support, like WebCrypto) and scientific applications AFAICS.. Hopefully Nuxt reverts that change, or at least provide an option for their customers to disable requiring that mostly useless feature.

Btw, I hope you don't take this as an attack against you webmasters, I totally understand that there's pretty much nothing you can do about it. It's just really frustrating to see most frameworks only cater to the three mainstream browser engines which are Blink, Gecko, and WebKit, totally ignoring the small, independent ones like ours (Goanna)...

That's a bug in Palemoon and unrelated to JS; we return a 204 on that endpoint most of the time, so there's no content to parse at all (hence that XML parsing error); see the response headers here for that request:

Confirmed, thanks! This is being worked on: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/2231

or if there's officially sanctioned trunk binaries somewhere we could use

I can build you one; I will just remove the official branding to avoid trouble with Moonchild's trademarks...

notably older Safari, where we currently are compatible with iOS 13 or so, tends to not adopt newer features particularly quickly

Totally off-topic to this thread, but I think this is a good thing, considering that most of the new "standards" are really just experimental features pushed by Google, with Mozilla rubberstamping most of them (since it only requires two votes to make a proposal a standard in WHATWG and eventually W3C, IIRC). I'm not really a fan of Apple, but I've got to admit that they're an important factor to keep the web standardization process from being completely dominated by Google. A lot of web developers are mad at WebKit for adopting features too slowly, causing cross-browser compat issues. Some even characterize Safari as the "new IE", which just isn't fair and should be a title given to Chrome... If those webdevs start thinking of just making their sites work fine across different modern browsers (no matter what the name of the engine they user is using) instead of adopting the new shiny which most likely aren't even useful for their websites, trust me, that self-imposed problem will go away and they will have far less technical debt in their code. TLDR: Just change only when necessary and you won't have a problem with Safari (and independent browsers like Pale Moon!)

Anyway, thanks very much for your responses! I have to admit it has gone better than I expected (most of the webmasters we contact would just ignore our messages to them). I really appreciate it, even if the official position is that we're an unsupported browser. Hopefully we can change that and keep that for at least a year or so.

 

[Mima-sama]

Unbranded trunk builds for Windows x64 are now available here: https://job.tilde.team/palemoon/20230505/

Hopefully none of your staff are Linux-exclusive

 

[AlexEliot]

According to a quick skim by one of our developers, it seems your framework is also requiring BigInt (tracked in UXP Issue #1240, note the lack of progress there), which totally doesn't make sense to require for websites like yours... I can understand dynamic module import being a pretty useful syntactic sugar compared to the previous, established imports from ES6, but BigInt... It's only useful for cryptography (and even in that niche there are alternatives which we support, like WebCrypto) and scientific applications AFAICS.. Hopefully Nuxt reverts that change, or at least provide an option for their customers to disable requiring that mostly useless feature.

Hello there, I don't think our website utilizes BigInt? I tried searching deep into our dependencies and it doesn't seem that there is one that uses it without providing a fallback if it's not supported. Additionally, I tried to set BigInt and BigInt64Array to undefined in a <script> element on the document's head and the site seemed to function properly on Chrome. The bit was injected before any nuxt/vue-related script was loaded so the possibility of it simply not being used after the site is rendered is ruled out.

<script>BigInt = undefined; BigInt64Array = undefined</script>

The only JavaScript code that run before this was the google recaptcha one.

I have tried the binary you've attached on your later message, but I seem to be getting the same error: SyntaxError: dynamic module import is not implemented. Apologies if I've misinterpreted and that feature is not implemented yet!

 

[Mima-sama]

I have tried the binary you've attached on your later message, but I seem to be getting the same error: SyntaxError: dynamic module import is not implemented. Apologies if I've misinterpreted and that feature is not implemented yet!

Whoops, you should enable "javascript.options.dynamicImport" in about:config first. Apologies for not mentioning that earlier...

 

[Mima-sama]

Btw if you guys want I can also provide a build that includes this pull request: https://repo.palemoon.org/MoonchildProductions/UXP/pulls/2231

The PR didn't fix the blank page issue, but it did fix the XML Parsing Error I mentioned earlier.

I also told the developer who said about your site having BigInt that you guys don't use BigInt in UXP Issue #1691.

 

[Ivegotnolife]

Hi, I'm trying to access a doujin: https://mangadex.org/title/1fd60886...been-an-incident-so-time-for-some-new-clothes

But it's only returning a blank page for me on Pale Moon, the browser I mainly use. When I looked at the browser's error console, it tells me that the site requires dynamic module import; luckily I regularly build from the browser's master branch (since I'm involved with Pale Moon's development), and the latest trunk just recently included an implementation of the said feature (which we track in UXP Issue #1691). I've enabled the feature as instructed by the pull request, and while the error about dynamic module import went away, it still returns a blank page. Looking at the error console again, it has given two different errors this time:

TypeError: o is undefined                                     entry.45e322df.js:1:14711
Stack trace:
setup@https://mangadex.org/_nuxt/entry.45e322df.js:75:175384
pn@https://mangadex.org/_nuxt/entry.45e322df.js:1:14205
D5@https://mangadex.org/_nuxt/entry.45e322df.js:1:64046
zm@https://mangadex.org/_nuxt/entry.45e322df.js:1:63831
S@https://mangadex.org/_nuxt/entry.45e322df.js:1:51341
D@https://mangadex.org/_nuxt/entry.45e322df.js:1:51234
p@https://mangadex.org/_nuxt/entry.45e322df.js:1:48108
Jw@https://mangadex.org/_nuxt/entry.45e322df.js:1:19604
process@https://mangadex.org/_nuxt/entry.45e322df.js:1:19350
p@https://mangadex.org/_nuxt/entry.45e322df.js:1:48146
z@https://mangadex.org/_nuxt/entry.45e322df.js:1:52314
run@https://mangadex.org/_nuxt/entry.45e322df.js:1:5082
G/F.update@https://mangadex.org/_nuxt/entry.45e322df.js:1:52583
G@https://mangadex.org/_nuxt/entry.45e322df.js:1:52609
S@https://mangadex.org/_nuxt/entry.45e322df.js:1:51437
D@https://mangadex.org/_nuxt/entry.45e322df.js:1:51234
p@https://mangadex.org/_nuxt/entry.45e322df.js:1:48108
le@https://mangadex.org/_nuxt/entry.45e322df.js:1:56330
mount@https://mangadex.org/_nuxt/entry.45e322df.js:1:43641
u2/t.mount@https://mangadex.org/_nuxt/entry.45e322df.js:1:83589
Mg@https://mangadex.org/_nuxt/entry.45e322df.js:75:177569

Timestamp: 4 May 2023 22:27:51
Error: XML Parsing Error: no root element found
Location: https://api.mangadex.org/auth/refresh
Line Number 1, Column 1:
Source File: https://api.mangadex.org/auth/refresh
Line: 1

Unfortunately I have no idea what is wrong, as the JavaScript is minified as hell. Without specifics on what is causing the issue, we won't be able to fix up what needs to be fixed up in our JavaScript engine, so as one of the browser's developers, please either provide a working fallback for browsers not supporting dynamic module import (this would be best IMO in the spirit of the open web) or tell us what JS cruft needs to be implemented so it can be triaged by us in our issue tracker. Thanks!

I hope this can be worked out. I was a real fan of PaleMoon till it was knocked off Firefox,
and had just rediscovered it before the NUXT migration made it unusable on this site.

 

[tristan9]

Unbranded trunk builds for Windows x64 are now available here

This is the next parsing error I get (trying to run against a local non-minified build) after enabling the dynamic import flag

Also @AlexEliot it seems like it does

I don't think our website utilizes BigInt?

At least grepping our prod client-side output I see:

$ rg -o 'BigInt' .
./entry.d2925253.js
1:BigInt
47:BigInt
47:BigInt
47:BigInt
47:BigInt
47:BigInt
47:BigInt
47:BigInt
47:BigInt

So there is indeed something outputing BigInt types. Doesn't mean that it is used though; and as far as I know Safari 13.x works fine (don't have a device to re-check that right now), and doesn't support it according to https://developer.mozilla.org/en-US...e/Global_Objects/BigInt#browser_compatibility so it shouldn't be necessary anyway

 

[tristan9]

If it helps, here's the entire file https://pastebin.com/41uCqKgU

 

[Mima-sama]

Thanks very much for the debugging, @tristan9! I think I have enough info now after your analysis and some digging online; seems like we don't support parsing "export async function" yet, which is a bit strange for us to have missed considering our recent work on asyncs... I've filed a new issue on our repo; you can track this at UXP Issue #2232.

 

[Mima-sama]

Oops, I spoke too soon. While the backport resolved the SyntaxError, it seems the TypeError (that is presumably causing the issue here) still remains...

With the SyntaxError resolved though, it means we can progress further in the debugging, so I will upload new trunk builds right now for you guys to use.

 

[Mima-sama]

New trunk builds have been uploaded: https://job.tilde.team/palemoon/20230506/

It's essentially current master + UXP PR #2233

 

[tristan9]

it seems the TypeError (that is presumably causing the issue here)

So the error still remains but isn't quite a type error; here's what's going on (testing your latest build):

import { useNuxtApp, useRoute } from "/_nuxt/node_modules/nuxt/dist/app/index.js?v=bd4495ba";

...

const _sfc_main = /* @__PURE__ */ _defineComponent({
  __name: "app",
  async setup(__props, { expose }) {
    expose();
    let __temp, __restore;
    const route = useRoute();
    const { $auth, $isMobileApp, $theme } = useNuxtApp();
    if ($auth.loggedIn) {
      const { initPersistentSettings } = usePersistentSettings();
      ;
      [__temp, __restore] = _withAsyncContext(() => initPersistentSettings()), await __temp, __restore();
    }
...

Specifically it fails on

    if ($auth.loggedIn) {

because $auth is undefined at this point (it's used for all conditionals between guests and logged-in users).

Now unfortunately, it fails silently here. I'm digging into what's happening lower to find where the actual issue lies

 

[tristan9]

Trying to put a breakpoint in the line just above however causes PM to instantly crash without any error message though. Not sure if PM has some kind of coredump feature.

Putting the breakpoint on the line of failure itself causes:

If I replace it with

if ($auth?.loggedIn) {

I do get a little further but not much; now our i18n module fails with:

SyntaxError: Need to install with `app.use` function

Which suggests that the root cause is that the hooks that install nuxt modules (which register extra state, functions, ...) aren't executed somehow, or their registration is lost.

At this point it's really difficult to know what's going on because of that debugger crash...

I tried to manually follow things and this is the call path to useNuxtApp:

// in app.vue

const _sfc_main = /* @__PURE__ */
_defineComponent({
    __name: "app",
    async setup(__props, {expose}) {
        expose();
        let __temp, __restore;
        const route = useRoute();
        const {$auth, $isMobileApp, $theme} = useNuxtApp();

And that useNuxtApp is:

export * from "/_nuxt/node_modules/nuxt/dist/app/nuxt.js?v=bd4495ba"; // <= this one exports it
export * from "/_nuxt/node_modules/nuxt/dist/app/composables/index.js?v=bd4495ba";
export * from "/_nuxt/node_modules/nuxt/dist/app/components/index.js?v=bd4495ba";
export * from "/_nuxt/node_modules/nuxt/dist/app/config.js?v=bd4495ba";
export const isVue2 = false;
export const isVue3 = true;

The first one being what we want, with:

import {getContext} from "/_nuxt/node_modules/.cache/vite/client/deps/unctx.js?v=bd4495ba";
const nuxtAppCtx = /* @__PURE__ */ getContext("nuxt-app");

...

export function useNuxtApp() {
    const nuxtAppInstance = nuxtAppCtx.tryUse();
    if (!nuxtAppInstance) {
        const vm = getCurrentInstance();
        if (!vm) {
            if (process.dev) {
                throw new Error("[nuxt] A composable that requires access to the Nuxt instance was called outside of a plugin, Nuxt hook, Nuxt middleware, or Vue setup function. This is probably not a Nuxt bug. Find out more at `https://nuxt.com/docs/guide/concepts/auto-imports#using-vue-and-nuxt-composables`.");
            } else {
                throw new Error("[nuxt] instance unavailable");
            }
        }
        return vm.appContext.app.$nuxt;
    }
    return nuxtAppInstance;
}

And finally that getContext call (which initializes it) is https://pastebin.com/AgrKDb4L from https://github.com/unjs/unctx

I have no idea if that helps, but until we can actually run the debugger that's the best I can do :/

 

[Mima-sama]

It seems to be still failing on the import, despite having the dynamic module import implementation enabled...

One of our devs did some more poking and found another bug in how we handle async functions and filed an issue for it in UXP Issue #2234. This seems to be the reason why we're stumped earlier with no error output at your earlier post, as the code inside the async scripts just simply never executes. It got fixed quickly while I'm asleep, and it seems we've got another error to deal with (this is a theme for us, don't worry), this time about import.meta:

While this does fix the issue with the Adobe Blog, the Mangadex page still fails to render. However, with this in place, it does reveal a different error message

SyntaxError: import.meta may only appear in a module
Stack trace:
Uu@https://mangadex.org/_nuxt/entry.45e322df.js:75:14174
T/<@https://mangadex.org/_nuxt/entry.45e322df.js:75:20481

The problem here is that lazily-created functions (e.g. anonymous/arrow/lamba functions), and the context (not sure of the correct term) that they're in is not set correctly. In other words, they're parsed as if their parent is a regular script, not a module script, which causes the import.meta issue. Mozilla addressed this in their implementation, but it involves a long string of import-related bugs that we haven't implemented yet.

I've found bug 1604792 which should provide clues as to what we're missing, but will require research to go down its chain of prerequisites.

I think we're pretty close to the root of the problem (I'd like to think this is actually causing the issue all along, but with several false leads earlier I don't want to be 100% sure lol). The import.meta issue seems pretty daunting as we haven't directly used Mozilla's implementation for dynamic module import, but I might try taking a stab at it, since pretty much everyone else doing work on Spidermonkey is busy irl right now...

Trying to put a breakpoint in the line just above however causes PM to instantly crash without any error message though. Not sure if PM has some kind of coredump feature.

Well that's concerning, the application shouldn't crash at all for just trying to use the JS debugger... We have an old, but still applicable (I think) guide on our forum which explains how to capture a minidump by hooking the browser up to WinDbg: https://forum.palemoon.org/viewtopic.php?f=19&t=13044

Though it might be easier for both of us if you can send me a testcase URL so I can try reproducing the crash myself while hooked up to Visual Studio.

 

[tristan9]

as the code inside the async scripts just simply never executes

Ah that would certainly explain it yes!

explains how to capture a minidump by hooking the browser up to WinDbg

I’ll give that a try later then

Though it might be easier for both of us if you can send me a testcase URL so I can try reproducing the crash myself while hooked up to Visual Studio.

Unfortunately that’d be difficult as our frontend isn’t meant to be open-source at the moment… maybe there’s a way to selectively add source maps in specific files only.

For now we should probably just wait for the fix regarding never executed async functions and import.meta calls, in case that ends up fixing everything

 

[Mima-sama]

Good news everyone! The import.meta issue has been resolved, and with it, Mangadex now finally renders in Pale Moon. The fixes will be shipped in the next 32.2.0 release which is upcoming this month.

Basilisk will also follow as it uses the same UXP platform as Pale Moon.

New trunk builds for the adventurous to try: https://job.tilde.team/palemoon/20230509/