Chromium's issue tracker page shows blank page

[hszrin]

When I visit Chromium's issue tracker page with Pale moon shows blank page without any content.

I tried on profile without any extension but it still doesn't works.

example URL: https://bugs.chromium.org/p/project-zer ... il?id=1944

Code: Select all

OS: Windows 10
Browser version: Pale Moon 28.7.1 (64-bit, Build ID=20190909125145)

(edit: screenshot re-uploaded)

[moonbat]

Can confirm, on Linux latest.
Browser console shows

Code: Select all

Use of captureEvents() is deprecated. To upgrade your code, use the DOM 2 addEventListener() method. For more help http://developer.mozilla.org/en/docs/DOM:element.addEventListener
TypeError: window.prpcClient is undefined
TypeError: window.getTSMonClient is not a function

[Moonraker]

I can confirm also.The links on that page work ok i should add.Probably the unknown browser syndrome and is shutting the door on non chromium based browsers perhaps.

[Moonchild]

Potentially it relies on events being global to windows instead of documents; it's a controversial change (because it might open cross-document holes and cause data leaks if not done extremely carefully) that isn't trivial to implement.

[moonbat]

Potentially it relies on events being global to windows instead of documents; it's a controversial change (because it might open cross-document holes and cause data leaks if not done extremely carefully) that isn't trivial to implement.

Off-topic:
Why would they do this, especially when they're already sandboxing browser tabs off into separate processes for security? Wouldn't it make more sense for each tab to continue to have its own event handling loop? Assuming any sense was involved in this design change of course.

[Moonchild]

Why would they do this, especially when they're already sandboxing browser tabs off into separate processes for security?

Because for multi-process use, it's not as much of an issue. If "windows" aren't actually windows but process containers, any risk is contained to those sandboxed processes (if everything goes as intended, that is... ). One could argue that this change was made specifically to punish single-process browsers, but more likely it's just sourced in wanting a lazy way to access events by making them as global as possible.

[Goodydino]

I see the same thing with Pale Moon and SeaMonkey. Slimjet shows the whole page normally. Probably so do Opera and Safari.

[Moonchild]

I see the same thing with Pale Moon and SeaMonkey. Slimjet shows the whole page normally. Probably so do Opera and Safari.

Chrome or clones will likely display properly, yes.
Doesn't mean non-chrome is at fault, per se. But considering the issue tracker is for Chrome, I'm pretty sure it's been assumed all devs interested in the bugs on it are using Chrome.

[JustOff]

As far as I can see this problem is due to the fact that UXP does not yet support ECMAScript modules (see bug #568953).

My research log:
1. mozregression pushlog includes bug #1428002 (Enable <script type="module"> in nightly builds)
2. Firefox 60 release is the first working version, see the notes for developers
3. Setting "dom.moduleScripts.enabled" to "false" in the current Firefox release breaks Chromium's issue tracker

[Moonchild]

Thanks for the research.
Well, it's an open issue which has many parts and is far from complete.