Avoiding collateral damage from javascript.options.strict

UNCONFIRMED
Unassigned

Status

()

Core
JavaScript Engine
P3
enhancement
UNCONFIRMED
a year ago
7 months ago

People

(Reporter: sworddragon2, Unassigned)

Tracking

({triage-deferred})

50 Branch
triage-deferred
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20161213225349

Steps to reproduce:

1. Set javascript.options.strict to true.
2. (As hypothetically your development work is now done) surf at some websites like YouTube without an opened web console.


Actual results:

A performance impact which depends how many javascript.options.strict warnings the site would throw (based on bug #1318178 which can be around 5 times higher on YouTube).


Expected results:

To quote me from bug #1318178 with 2 suggestions:

> Maybe the question is what this option is used for. For me it is to check my
> own sites for these compiler-like warnings to improve the quality - I'm
> normally not interested to see them in sites I browse and do not develop. It
> could be useful to change javascript.options.strict from a boolean to a
> string which is a regular expression of sites where this option gets enabled
> (for example the user could use then ^(file://|https?://localhost([#/?]|))
> to enable this option only for sites on the file protocol and the local
> webserver). Alternatively this option could be changed to be site-driven
> instead of being a client-sided option. For example sites could opt-in
> strict warnings with a pragma (similar to 'use strict';) if they want to
> show these additional warnings.
(Reporter)

Updated

a year ago
Severity: normal → enhancement

Updated

a year ago
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Keywords: triage-deferred
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.