1283167 - Remove MOZ_SELFHOSTEDJS

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[wahib-mkadmi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

1) Built Firefox from source (Tried 45 ESR, 46, 47) 
2) Invoked JS shell with the following: 
Wahib MKADMI@TayebTube ~/obj-i686-pc-mingw32/js/src
$ MOZ_SELFHOSTEDJS='./selfhosted.js' ./js

_______
Steps listed in the last section of this page: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/self-hosting


Actual results:

Error then crash: 

Assertion failure: IsGlobalLexicalScope(scopeChain) || script->hasNonSyntacticScope() (Only global scripts with non-syntactic scopes can be executed with interesting scopechains), at e:/Projects/Firefox/45-esr/js/src/vm/Interpreter.cpp:670

Firefox crashes without error.


Expected results:

Load selfhosted.js for testing.

Comment 1

[wahib-mkadmi]

Forgot to specify, selfhosted.js is vanilla, still haven't touched it. 

Thanks, and keep up the good work.

Comment 2

[Jason Orendorff [:jorendorff]]

Running a browser build now to see if I can reproduce this.

I wonder if this environment variable is honored when running the browser. It shouldn't be: this feature is for engine hackers only. Right?

Comment 3

[wahib-mkadmi]

Hi, 

Thanks for your interest on the issue. 

I believe it is honored, have tested it. (Changed env var name, no error, changed file name: the regular no file found, so it's definitely honored).

It is indeed for engine hackers.

Comment 4

[Jason Orendorff [:jorendorff]]

Hmm. I can't reproduce this using the latest sources. Maybe it was fixed recently. How are you building JS?

Comment 5

[wahib-mkadmi]

I built it along with the whole browser (mach build). 
What other info do I need to provide ? (I'm still quite new to Mozilla source)

Comment 6

[wahib-mkadmi]

Here's the selfhosted.js I'm trying to use, just in case http://pastebin.com/nZ2iQyUZ
It loads correctly when compiled and ran in the browser.

Comment 7

[Jason Orendorff [:jorendorff]]

(In reply to wahib-mkadmi from comment #5)
> I built it along with the whole browser (mach build). 

That's what I wanted to know.

----

I talked with Till, who added this feature. He thinks it's no longer necessary. Changes to self-hosted code can be done directly in the source files (such as js/src/builtin/Object.js).

After changing something, you'll have to rebuild, but that's not so bad. Rebuilds are faster now than they were when MOZ_SELFHOSTEDJS was originally added.

Comment 8

[wahib-mkadmi]

Pardon my ignorance, but how does that relate to the error I'm encountering ?

Anyway, I downloaded the latest beta source, and built it and got my selfhosted.js, still the same problem, tried to run even in VM.

How are you setting your build up ? How are you successfully doing it ?

Comment 9

[Jason Orendorff [:jorendorff]]

Attachment: Remove MOZ_SELFHOSTEDJS

MozReview-Commit-ID: 6AqQsiNe6zN

Comment 10

[wahib-mkadmi]

I see you removed MOZ_SELFHOSTEDJS, is there an alternative ?

Comment 11

[Till Schneidereit [:till]]

Comment on attachment 8766601 [details] [diff] [review]
Remove MOZ_SELFHOSTEDJS

Review of attachment 8766601 [details] [diff] [review]:
-----------------------------------------------------------------

Thank you.

Comment 12

[Till Schneidereit [:till]]

(In reply to wahib-mkadmi from comment #10)
> I see you removed MOZ_SELFHOSTEDJS, is there an alternative ?

Can you say a bit more about what you want to do? MOZ_SELFHOSTEDJS is just a debugging help for working on self-hosted JS that allows (allowed) one to test changes and add debug logs without recompiling. As Jason said above, that's less important than it used to be because touching self-hosted JS doesn't cause multi-minute build times for the browser anymore.

Comment 13

[wahib-mkadmi]

(In reply to Till Schneidereit [:till] from comment #12)

> Can you say a bit more about what you want to do? 

I'm trying to modify the behavior of the internationalization API for the built in modules, for example, for date, when `date.toLocaleString()` is called, I want to hook it so it returns the result formatted in a locale I provide (using registry, config file, you name it..) without changing the browser/system language. MOZ_SELFHOSTEDJS used to provide a simple way to do it since we dealt with plain JavsScript. 

> less important than it used to be because touching self-hosted JS doesn't cause multi-minute build times for the browser anymore.
So mach build on top of the built firefox will relaod self-hosted js ?

Comment 14

[Jeff Walden [:Waldo]]

(In reply to wahib-mkadmi from comment #13)
> I'm trying to modify the behavior of the internationalization API for the
> built in modules, for example, for date, when `date.toLocaleString()` is
> called, I want to hook it so it returns the result formatted in a locale I
> provide (using registry, config file, you name it..) without changing the
> browser/system language. MOZ_SELFHOSTEDJS used to provide a simple way to do
> it since we dealt with plain JavsScript.

That's...an interesting use case.  And calling JS_SetDefaultLocale won't work because that would affect the rest of JS's behavior in the browser, including in chrome code?  That's really the supported API to determine how locale-aware Intl APIs should work without an explicitly chosen locale.

In any event, I don't think it's one that supports preserving MOZ_SELFHOSTEDJS as an "interface".  It might have "worked" for that purpose, but so many things can go wrong with miswritten self-hosted JS that it's really pretty dangerous for this to be an API.

(I'd be willing to bet the rest of the British currency I have on me, at the tail end of a trip to Britain, that your self-hosted JS causes observable deviations from specification requirements.  It'd be near-trivial for your changes to have security/stability/reliability ramifications, because of how fragile self-hosted code is.)

Comment 15

[Jason Orendorff [:jorendorff]]

Well... since you're building a browser anyway, you could patch js/src/builtin/Intl.js. But depending on what you're doing, that may not solve your problem.

Can you tell us more about what you're trying to do? What locale? Ideally we'd support your locale natively.

Comment 16

[wahib-mkadmi]

(In reply to Jeff Walden [:Waldo] (remove +bmo to email) from comment #14) 
> That's...an interesting use case.  And calling JS_SetDefaultLocale won't
> work because that would affect the rest of JS's behavior in the browser,
> including in chrome code?  That's really the supported API to determine how
> locale-aware Intl APIs should work without an explicitly chosen locale.
> 
> In any event, I don't think it's one that supports preserving
> MOZ_SELFHOSTEDJS as an "interface".  It might have "worked" for that
> purpose, but so many things can go wrong with miswritten self-hosted JS that
> it's really pretty dangerous for this to be an API.
> 
> (I'd be willing to bet the rest of the British currency I have on me, at the
> tail end of a trip to Britain, that your self-hosted JS causes observable
> deviations from specification requirements.  It'd be near-trivial for your
> changes to have security/stability/reliability ramifications, because of how
> fragile self-hosted code is.)

I didn't originally intend to change any logic except the code that decides which locale is finally to be used, but I guess I'm finally going with the JS_SetDefaultLocale approach.
I wouldn't place much bet on that though neither lol. 

(In reply to Jason Orendorff [:jorendorff] from comment #15)
> Well... since you're building a browser anyway, you could patch
> js/src/builtin/Intl.js. But depending on what you're doing, that may not
> solve your problem.
> 
> Can you tell us more about what you're trying to do? What locale? Ideally
> we'd support your locale natively.

My project is actually about an advanced fingerprint-spoofing browser. A common fingerprinting technique is using the toLocaleString methods as a fingerprinting vector. So I want to be able to modify the (default ?) locale to be used - more like https://trac.torproject.org/projects/tor/attachment/ticket/13019/0001-Bug-5926-Spoof-default-JavaScript-locale-as-en-US.patch but give the user the choice of this locale (through a separate software), but **without** affecting the language of the UI.

Comment 17

[Jason Orendorff [:jorendorff]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9193c55ec783c7d2bf7049d6c28944e60b5fe612
Bug 1283167 - Remove MOZ_SELFHOSTEDJS. r=till.

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/9193c55ec783