Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dartium: need a way to turn on checked mode from the HTML page #3092

Closed
jmesserly opened this issue May 16, 2012 · 21 comments
Closed

Dartium: need a way to turn on checked mode from the HTML page #3092

jmesserly opened this issue May 16, 2012 · 21 comments
Assignees
Labels
closed-duplicate Closed in favor of an existing report
Milestone

Comments

@jmesserly
Copy link

To turn on checked mode in Dartium, you have to set an environment variable. This means the checked mode setting applies globally to all web pages and apps, and has to be specified by the end user not the developer.

Something is not right with this picture :)

I'd like to be able to configure this in the HTML page. For now it'd be nice to have something simple like this:
  navigator.webkitStartDart({ checked: true });

Ultimately it might make more sense to be specified per script tag. That's kind of tricky but here are some ideas:

... with a new attribute:
  <script type="application/dart" src="list_example.dart" flags="checked">

... abusing mime-type:
  <script type="application/dart+checked" src="list_example.dart">

... or have a way to declare the mode in the Dart source with a # directive.
  <script type="application/dart">
    #option checked
    #import ...

@DartBot
Copy link

DartBot commented May 17, 2012

This comment was originally written by antonm@google.com


If we can control checked mode per isolate level via embedder's API, that should be trivial to add.

However, why not open a separate instance of Dartium with different profile?


cc @a-siva.
cc @iposva-google.

@DartBot
Copy link

DartBot commented Jun 1, 2012

This comment was originally written by antonm@google.com


Added this to the Later milestone.

@jmesserly
Copy link
Author

I don't really want to use a different profile, and have to put it somewhere and have different bookmarks and autocomplete history and stuff. It's useful to have the Chromium profile remember those things. Plus it's not very discoverable (also a problem with the environment variable).

I don't understand how we can get Dart into real Chrome when such an important language feature is configured via global environment variable at launch time...

However, on the development side, this is quite a bit better now that the Editor makes it easy to configure and now that it defaults to checked mode.

@DartBot
Copy link

DartBot commented Mar 27, 2013

This comment was originally written by antonm@google.com


I am going to close it, please, reopen if you think it's very important to have.


Added AsDesigned label.

@jmesserly
Copy link
Author

yes, this is important!

We cannot have important properties of Dart in Chrome be affected by environment variables.
Here's an analogy: what if ES5 strict mode was configured via JS_FLAGS="--strict-mode" on the command line.

It seems totally crazy. You can't ask users to open their browser with a magic environment variable.

The HTML page needs to control these.


Added Triaged label.

@jmesserly
Copy link
Author

cc @dgrove.

@dgrove
Copy link
Contributor

dgrove commented Mar 28, 2013

I agree with John here - we need a way of controlling this inside the browser (and really, per-tab).

@vsmenon
Copy link
Member

vsmenon commented Mar 28, 2013

Does the VM support Anton's suggestion in #­1? If not, we should file the appropriate bug over there.

@iposva-google
Copy link
Contributor

Does the VM support Anton's suggestion in #­1?
There are three suggestions in comment 1.

This is something we want to support:
  <script type="application/dart" src="list_example.dart" flags="checked">
It means that you can set certain flags (e.g. checked mode, resource limits) on a per isolate basis. We need this for Dartium, but also for other embedders.

This is not something we will support:
  <script type="application/dart">
    #option checked
    #import ...

The third suggestion (abusing mime type) is the same as the first from the VM perspective, as the bindings could pass us the flag when recognizing the special mime type. But very wrong on other aspects: Need to have a special mime type for every possible flag (including cross product), layers in between would potentially need to know how to handle these special mime types, ...

@jmesserly
Copy link
Author

Thanks Ivan. Yeah looking back on this now (with some months of hindsight), the flags= seems like the only sensible one of my 3 suggestions :). Maybe there are other ideas, though.

@dgrove
Copy link
Contributor

dgrove commented Mar 28, 2013

+1 to flags="checked". I think this would work very well.

@vsmenon
Copy link
Member

vsmenon commented Mar 28, 2013

Alternatively, something like this in the header:

<meta name="dart-flags" content="checked">

This is probably safer than adding an attribute to the script tag. Strictly speaking, your html won't validate if you throw custom attributes in there (and data-* attributes are supposed to be ignored by the browser according to spec).

@vsmenon
Copy link
Member

vsmenon commented Mar 28, 2013

Filed a blocking bug on the VM.


Marked this as being blocked by #9498.

@DartBot
Copy link

DartBot commented Mar 29, 2013

This comment was originally written by antonm@google.com


Just a thing to consider: what happens to isolates spawned? Most sensible behaviour seems to be they inherit the mode from the parent isolate. Any hidden issues?

@vsmenon
Copy link
Member

vsmenon commented Mar 29, 2013

Most sensible behaviour seems to be they inherit the mode from the parent isolate. Any hidden issues?

This makes sense to me. I think it would be simpler to have a setting for the page rather than per script tag (e.g., the meta tag approach), so you don't mix and match on the same page. I think this would also make the DartController logic simpler, but perhaps not.

@DartBot
Copy link

DartBot commented Mar 29, 2013

This comment was originally written by antonm@google.com


Let's see how embedder's API will shape out, but technically the same VM can run isolates for various pages, so my immediate reaction is implementation-wise page granularity won't make things simpler.

@vsmenon
Copy link
Member

vsmenon commented Mar 29, 2013

Right, I was thinking one set of flags per DartController that'd be passed into each Dart_CreateIsolate.

@vsmenon
Copy link
Member

vsmenon commented Sep 13, 2013

Tentatively bumping to M7.

Siva: can you look at 9498 and decide whether we should support this in M7 or push later?


Set owner to @a-siva.
Removed this from the Later milestone.
Added this to the M7 milestone.

@vsmenon
Copy link
Member

vsmenon commented Oct 2, 2013

Removed this from the M7 milestone.
Added this to the M8 milestone.

@crclayton
Copy link

Did anything ever come of this?

@jmesserly
Copy link
Author

I believe most of our Dart-IDE plugins will launch Dartium in checked mode for a while now.
And with dart2js you can also enable checked mode.
(dart dev compiler, which we are working on, is also in checked mode.)

dart-bot pushed a commit that referenced this issue Sep 14, 2021
New commits in this revision:

git log --format=%C(auto) %h %s cafadd17ba285dad9ebe6d34c617bc0d70d096b3..98a01e1cdbf441f030f1be76417860b6b372663d ✓
 cafadd17 Don't use null safety (yet) (#3112)
 98a01e1c Store credentials in a config directory (#3092)
 4ee280b7 Fixed messages (#3110)
 bbdac802 Third party hosted pub registry authentication (#3007)
 b1bedc53 `--examples` for get/upgrade/downgrade/add/remove (#2857)

Change-Id: Ibf6ffe33820c97114958c1564a7c22a46ff73d9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213348
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed-duplicate Closed in favor of an existing report
Projects
None yet
Development

No branches or pull requests

7 participants