question about Pale Moon JS Engine Topic is solved

[noellarkin]

When I run this in the browser console:

Code: Select all

function getEngine() {
    const x = [].constructor;
    try {
        (-1).toFixed(-1);
    } catch (err) {
        return err.message.length + (x+'').split(x.name).join('').length;
    }
}

console.log(getEngine());

in Firefox, I get 58, in Pale Moon it's `undefined`. I'm curious why this is the case.

Why: after a previous thread about Pale Moon emulating Firefox fingerprints (here: viewtopic.php?f=5&t=31218) , I started looking into the differences between how Pale Moon and Firefox report fingerprints (and how websites/scripts do feature detection). One of the differences seems to be the JS engine reporting in the above example.

Here's a code snippet I found on Github:

Code: Select all

// Detect Browser
function getEngine() {
	const x = [].constructor
	try {
		(-1).toFixed(-1)
	} catch (err) {
		return err.message.length + (x+'').split(x.name).join('').length
	}
}

const ENGINE_IDENTIFIER = getEngine()
const IS_BLINK = ENGINE_IDENTIFIER == 80
const IS_GECKO = ENGINE_IDENTIFIER == 58
const IS_WEBKIT = ENGINE_IDENTIFIER == 77
const JS_ENGINE = ({
	80: 'V8',
	58: 'SpiderMonkey',
	77: 'JavaScriptCore',
})[ENGINE_IDENTIFIER] || null

[FranklinDM]

Likely bug 1367791.

We don't throw a range error because we're still accepting a larger negative range. That check fails since it expects that an exception will be thrown and takes the string length of the error message.

[noellarkin]

Thanks for looking into it. Is the large negative range essential for the engine's functioning? I'm wondering if the edit suggested in https://hg.mozilla.org/mozilla-central/rev/03533ecbc1af can be applied to Pale Moon as well.

[FranklinDM]

I've filed Issue #2531 (UXP) for this.

Updating the allowed range should be a straightforward fix, but I'm not exactly sure if there are any extensions or browser JS code that relies on this specific behavior.

[Moonchild]

That check fails since it expects that an exception will be thrown and takes the string length of the error message.

That's a TERRIBLE way of determining which JS engine is in use. Really now? Relying on the length of a plaintext error message thrown...?

[noellarkin]

That's a TERRIBLE way of determining which JS engine is in use. Really now? Relying on the length of a plaintext error message thrown...?

I agree, but it seems to be in use. A quick synopsis of how I stumbled upon it:

I was trying to understand how different feature detection algorithms respond to Pale Moon's "Native" mode vs "Compatibility" mode.
I went to this site, which has a collection of widely used feature detection methods: https://abrahamjuliot.github.io/creepjs/
and compared the results between Pale Moon's Native mode, Firefox Compatibility mode and an actual Firefox browser.
Whenever I switched to PM's Compatibility mode I'd get an error saying "null JS runtime and SpiderMonkey user agent do not match" and it would lower the "browser integrity score". I dug into the source code and found the code snippet posted in the thread.

[noellarkin]

I compiled Pale Moon with the changes mentioned here: https://hg.mozilla.org/mozilla-central/rev/03533ecbc1af
Binaries removed
Seems to be working fine for me, and the engine is now being recognized as spidermonkey by feature detection tests.

[Moonchild]

Issue #2543 (UXP)

Critical note: please remove the Mega.nz hosted binaries. You shouldn't build test versions with official branding and disseminate them with it.

[Moonchild]

Both spec issues have been fixed now - will be in 33.3.0

[noellarkin]

Issue #2543 (UXP)
Critical note: please remove the Mega.nz hosted binaries. You shouldn't build test versions with official branding and disseminate them with it.

ah, sorry about that, didn't know. Removed them.