Closed Bug 1382377 Opened 7 years ago Closed 7 years ago

Consider making the console API no-op when the devtools add-on isn't installed

Categories

(Core :: DOM: Core & HTML, enhancement, P2)

Product:
Core
Component:
DOM: Core & HTML
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla57
Tracking Flags:
Tracking Status
firefox57 --- fixed

People

(Reporter: ehsan.akhgari, Assigned: ochameau)

References

(Depends on 1 open bug)

Details

Attachments

(2 files)

Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.
59 bytes, text/x-review-board-request
baku
: review+
jdescottes
: review+
Details
Bug 1382377 - Test console against devtools.enabled pref.
59 bytes, text/x-review-board-request
baku
: review+
Details 
I have noticed when profiling that if you have a console.log() in a hot loop or something similar, that typically shows up in your profile which isn't great.  With devtools moving to become a system add-on which isn't installed by default, it'd be nice to make these APIs no-op by default if the devtools add-on isn't installed.

Needinfoing baku since he knows a lot about the implementation of the console API to think about the options we have here.
Flags: needinfo?(amarchesini)
The devtools add-on will be installed automatically for Nightly and DevEdition users and (starting in Firefox 57?) not for Beta or Release users. Bryan Clark says the devtools add-on will be listed in about:addons so developers can install or uninstall it for testing.

Both the devtools and browser consoles will be unable for users without the devtools add-on, so it seems like all console logging can become a no-op.
Yes. This is nice to have and not complex to do. The only difference is that we will not be able to show old messages logged by a page, if devtools are installed after the logging. But this doesn't seem a serious issue.

Is there anything in place I can use to know if devtools are installed or not? Plus it's important to have notifications when devtools are installed and uninstalled (or enabled/disabled as addon).
Flags: needinfo?(amarchesini) → needinfo?(cpeterson)
(In reply to Andrea Marchesini [:baku] from comment #2)
> Is there anything in place I can use to know if devtools are installed or
> not? Plus it's important to have notifications when devtools are installed
> and uninstalled (or enabled/disabled as addon).

Joe, what is the recommended method for Gecko code to check whether the devtools add-on is installed and enabled?
Flags: needinfo?(cpeterson) → needinfo?(jwalker)
Bouncing needinfo to Alex
Flags: needinfo?(jwalker) → needinfo?(poirot.alex)
Depends on: 1382968
Are you seeing the overhead of ContentProcessSingleton.js ?
I discovered that two days ago and was working on this. I just opened bug 1382968.

Looking for devtools add-on being installed or not installed is a good first step,
but it will still make all the engineering working against Nightly/m-c and all the web developers have a slower Firefox.

Bug 1359855 is a good example. We got the same reaction, me included, saying let's wait for devtools to be an add-on,
but at the end we could improve firefox startup even for web developer having the devtools installed.

If bug 1382968 isn't enough and you want to cut some call even before the console-api-log-event, the same applies.

Here is a couple of checks we could do:
* Are devtools installed?
  It will always be true on 56. And may be also 57, if we don't get the green light to do that during that special release. And keep in mind it will always be installed on Nightly.

  An efficient check is this one:
    Services.io.getProtocolHandler("resource")
            .QueryInterface(Ci.nsIResProtocolHandler)
            .hasSubstitution("devtools")
  There is this module exposing an explicit flag:
    http://searchfox.org/mozilla-central/source/devtools/shim/DevToolsShim.jsm
    DevToolsShim.isInstalled
 
* Are devtools initialized?
  It means that the user fired any devtools entrypoint: command line argument, key shortcut, inspect-node context-menu...
  You will be able to check this via this JSM, but it depends on bug 1382173 and 1359855:
  http://searchfox.org/mozilla-central/source/devtools/shim/DevToolsShim.jsm
  DevToolsShim.isInitialized
  If being exposed from a JSM is an issue, we could move that "isInitialized" flag to our core xpcom:
  http://searchfox.org/mozilla-central/source/devtools/client/devtools-startup.js
  so that you can more easily access it from c++

* Is there any console up and running?
  I don't know any API that would mean that, but that should be easy to expose something from devtools.

* Is there a console up and running interested about this document?
  Sounds like much more work. That would be a new API to define and implement between DOM and devtools.
Thanks Alexandre for your comment. Having DevToolsShim.isInstalled exposed to xpcom makes my life easier yes. Plus I need a notification when devtools are uninstalled/installed.
(In reply to Alexandre Poirot [:ochameau] from comment #6)
> Are you seeing the overhead of ContentProcessSingleton.js ?
> I discovered that two days ago and was working on this. I just opened bug
> 1382968.

I believe so, yes!
Priority: -- → P2
Flags: needinfo?(poirot.alex)
Quick update.

I'm still looking at making the console faster, that, without completely disabling it.
So that it will benefit to Web Developer...
Profiler numbers goes from 4517ms down to 1454ms with bug 1382968, down to 943ms with bug 1388709 on a test case using console log heavily.

But we are still planing to come up with a complete no-op mechanism.
As shipping DevTools as an add-on is still at risk for 57 cycle, we are planning to introduce the "DevTools Shim UI" (bug 1361080) in 57. But instead of installing the add-on, it will only enable/disable a preference. Something like "devtools.enabled".

This pref would be false by default. Any DOM/DevTools codebase would act accordingly to this pref and make everyhing no-op.
DevTools would still add menu entries, key shortcuts, but these are only hooks (landed in bug 1359855).
This first time you trigger any of these hooks, it will open a "DevTools Enabling/Installation UI" (bug 1361080).
This page will tell you about DevTools and you would have to confirm before it turns the preference on.

Then, whenever the DevTools Add-on is ready to ship, this page would also download and install the add-on before toggling the preference.
Depends on: dt-addon-uishim
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

Chris, I'm looking for feedback on this patch. I'll most likely wait for :baku to come back from PTO for full review, but that would be great to confirm that's not a completely wrong approach.
(feel free to redirect to whoever makes sense!)

This patch introduces "devtools.enabled" pref.
Here set to true by default. So you have to manually turn it to false to try this patch. This pref is automatically set to true when opening the tools.
Console native codebase no-op itself by looking at this pref value.
Attachment #8895349 - Flags: feedback?(cpeterson)
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

(In reply to Alexandre Poirot [:ochameau] from comment #11)
> Chris, I'm looking for feedback on this patch. I'll most likely wait for
> :baku to come back from PTO for full review, but that would be great to
> confirm that's not a completely wrong approach.
> (feel free to redirect to whoever makes sense!)

Olli, can you take a look at the DOM bits of Alex's patch to neuter to devtools console APIs? Or suggest another DOM person to provide feedback until Baku returns from PTO for a full review?


> This patch introduces "devtools.enabled" pref.
> Here set to true by default. So you have to manually turn it to false to try
> this patch. This pref is automatically set to true when opening the tools.
> Console native codebase no-op itself by looking at this pref value.

Does Console.cpp handle both the devtools web console (Ctrl+Shift+K) and the browser console (Ctrl+Shift+J)?
Attachment #8895349 - Flags: feedback?(cpeterson) → feedback?(bugs)
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

https://reviewboard.mozilla.org/r/166546/#review171814

::: devtools/shim/devtools-startup-prefs.js:25
(Diff revision 1)
> +
> +// TODO
> +// - implement enabling UI before setting it to false by default
> +// - fix tests that fails when it is false by default
> +// - make it set to true on fennec
> +pref("devtools.enabled", true);

Maybe `devtools.initialized` is a better name, since it's about (I think!) DevTools being _installed and ready_ not _toolbox open_?  `enabled` makes me think "a toolbox is open right now".
(In reply to Chris Peterson [:cpeterson] from comment #13)
> > This patch introduces "devtools.enabled" pref.
> > Here set to true by default. So you have to manually turn it to false to try
> > this patch. This pref is automatically set to true when opening the tools.
> > Console native codebase no-op itself by looking at this pref value.
> 
> Does Console.cpp handle both the devtools web console (Ctrl+Shift+K) and the
> browser console (Ctrl+Shift+J)?

Yes. Console.cpp ends up calling ConsoleAPIStorage.js:RecordEvent, itself dispatching console-api-log-event observer service notifcation, which is listened by WebConsoleActor from DevTools. This actor is used for both Web Console and Browser Console. This differences are where the actor lives (parent or content process) and how it filters message (browser console basically accept everything).


(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #14)
> Comment on attachment 8895349 [details]
> Maybe `devtools.initialized` is a better name, since it's about (I think!)
> DevTools being _installed and ready_ not _toolbox open_?  `enabled` makes me
> think "a toolbox is open right now".

You are right, it doesn't mean a toolbox is opened.
It sounds more like "developer mode ON".
In the scope of this bug, it may look like it will only change low level things.
But in the scope of bug 1361080, bug 1378397 and go faster initiative, it may have more impact.
The pref value will most likely match the add-on installation state. uninstalled=false, installed=true.
For example, if the add-on is not installed, menus won't contain all existing devtools entries.
Instead, it would only expose a "Enable Developer Tools" one.
We already discussed about that during Go Faster meeting, and "installed" may be another option. It better highlights the fact that, before you turn the pref ON, it wasn't there and so it wasn't listening.

With such additional data, what do you think about the three options?
- devtools.initialized
- devtools.enabled
- devtools.installed
(or yet another new one? ;))
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

https://reviewboard.mozilla.org/r/166546/#review171918

::: dom/console/Console.cpp:830
(Diff revision 1)
> +    if (!sPrefCacheInited) {
> +      Preferences::AddBoolVarCache(&sDevToolsEnabled, "devtools.enabled");
> +      sPrefCacheInited = true;
> +    }
> +  } else {
> +    sDevToolsEnabled = true;

Why are we reinitializing this to true when running on non-main thread? Does this mean that if there is no devtools and one first uses console on main thread and then on a worker, console gets enabled again.
Attachment #8895349 - Flags: feedback?(bugs)
(In reply to Olli Pettay [:smaug] from comment #16)
> Comment on attachment 8895349 [details]
> Bug 1382377 - Make Console API be a no-op until DevTools are opened at least
> once.
> 
> https://reviewboard.mozilla.org/r/166546/#review171918
> 
> ::: dom/console/Console.cpp:830
> (Diff revision 1)
> > +    if (!sPrefCacheInited) {
> > +      Preferences::AddBoolVarCache(&sDevToolsEnabled, "devtools.enabled");
> > +      sPrefCacheInited = true;
> > +    }
> > +  } else {
> > +    sDevToolsEnabled = true;
> 
> Why are we reinitializing this to true when running on non-main thread? Does
> this mean that if there is no devtools and one first uses console on main
> thread and then on a worker, console gets enabled again.

Ok. Here is the thing: I'm not used to write C++ patches, even less one involving threads!
I didn't knew how to propagate the preference information back to the non-main threads.
So my intent here was to keep the console enabled on non-main threads,
they will still propagate the calls to the main thread (via ConsoleCallDataRunnable),
but the main thread will follow the preference and still block worker logs.

Now that I write that down, I realize that I should propably also make a check into ProcessCallData.

But I feel that I just misunderstood how threading work.
Are statics variables shared and accessible across threads?
If so, yes, these lines are completely misleading!!
(In reply to Alexandre Poirot [:ochameau] from comment #15)
> 
> With such additional data, what do you think about the three options?
> - devtools.initialized
> - devtools.enabled
> - devtools.installed
> (or yet another new one? ;))

My 2 cents here. I think installed > enabled > initialized all fit 3 different times of the lifecycle that will be very relevant when DevTools is an addon.

- installed : DevTools addon is installed/downloaded
- enabled : DevTools addon is enabled
- initialized : DevTools has loaded & initialized all the startup code (ie Loader + devtools-browser)

For now the installed and enabled step are _always_ satisfied because DevTools is built in Firefox. I like the devtools.enabled proposal because it maps well to the "enabled" step I described above. And I would like to avoid installed/initialized for the same reason.

We could also imagine it as a new intermediary thing between "enabled" and "initialized". "available" maybe?
(In reply to Julian Descottes [:jdescottes] from comment #18)
> (In reply to Alexandre Poirot [:ochameau] from comment #15)
> > 
> > With such additional data, what do you think about the three options?
> > - devtools.initialized
> > - devtools.enabled
> > - devtools.installed
> > (or yet another new one? ;))
> 
> My 2 cents here. I think installed > enabled > initialized all fit 3
> different times of the lifecycle that will be very relevant when DevTools is
> an addon.
> 
> - installed : DevTools addon is installed/downloaded
> - enabled : DevTools addon is enabled
> - initialized : DevTools has loaded & initialized all the startup code (ie
> Loader + devtools-browser)
> 
> For now the installed and enabled step are _always_ satisfied because
> DevTools is built in Firefox. I like the devtools.enabled proposal because
> it maps well to the "enabled" step I described above. And I would like to
> avoid installed/initialized for the same reason.
> 
> We could also imagine it as a new intermediary thing between "enabled" and
> "initialized". "available" maybe?

These are good points, I agree it's better to be clear about each lifecycle stage.  Someone should write them down for future reference once names are chosen! :)

I think in terms of pref names, "enabled" is easier for me to parse if it's clear we aren't talking about toolboxes.  There are many parts of DevTools as a whole that may or may not be enabled.  What if we make the names more specific by adding "addon" or "shim" or something?

Since it's the shim layer that appears to set the pref, maybe "devtools.shim.enabled"?
(In reply to Alexandre Poirot [:ochameau] from comment #17)
> But I feel that I just misunderstood how threading work.
> Are statics variables shared and accessible across threads?
Yes.
You may want to look at WorkerPrefs.h
(In reply to Olli Pettay [:smaug] from comment #20)
> (In reply to Alexandre Poirot [:ochameau] from comment #17)
> > But I feel that I just misunderstood how threading work.
> > Are statics variables shared and accessible across threads?
> Yes.

Ok, so I was just completely misunderstanding things...

I pushed a new patch removing the:
+  } else {
+    sDevToolsEnabled = true;

This boolean is set correctly by the main thread, which should always exists as the workers send back the messages to the main thread. I don't think we need to use WorkerPrefs thanks to this shared boolean.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #19)
>
> I think in terms of pref names, "enabled" is easier for me to parse if it's
> clear we aren't talking about toolboxes.  There are many parts of DevTools
> as a whole that may or may not be enabled.  What if we make the names more
> specific by adding "addon" or "shim" or something?
> 
> Since it's the shim layer that appears to set the pref, maybe
> "devtools.shim.enabled"?

Ah. Naming...

devtools.shim.enabled doesn't work well as the shim is always up and running.
What we call shim are mostly devtools-startup.js and DevToolsShim.jsm,
which hook Firefox UI and manage the interaction between Firefox and DevTools codebase.

devtools.addon.enabled doesn't work well today as we still have no DevTools add-on in mozilla-central.

After briefly looking at what else we could disable, I haven't found anything else obvious.
So devtools.console.enabled could be an option if we end up only turning this platform code off.
But we should probably send a message to dev-platform to see if anyone knows about some other pieces of code we could disable.
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

https://reviewboard.mozilla.org/r/166546/#review176360

Looks good to me for the DevTools part.
Attachment #8895349 - Flags: review?(jdescottes) → review+
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

https://reviewboard.mozilla.org/r/166546/#review177258

::: dom/console/Console.cpp:823
(Diff revision 3)
>    , mInnerID(0)
>    , mStatus(eUnknown)
>  {
>    MOZ_ASSERT_IF(NS_IsMainThread(), aWindow);
>  
> +  static bool sPrefCacheInited = false;

This is not good. What about if the console is used just in workers?

I suggest to add a nsContentUtils::DevToolsEnabled() method that do this code on main-thread and in workers it uses WorkerPrefs.h.
Attachment #8895349 - Flags: review?(amarchesini) → review-
(In reply to Andrea Marchesini [:baku] from comment #27)
> Comment on attachment 8895349 [details]
> Bug 1382377 - Make Console API be a no-op until DevTools are opened at least
> once.
> 
> https://reviewboard.mozilla.org/r/166546/#review177258
> 
> ::: dom/console/Console.cpp:823
> (Diff revision 3)
> >    , mInnerID(0)
> >    , mStatus(eUnknown)
> >  {
> >    MOZ_ASSERT_IF(NS_IsMainThread(), aWindow);
> >  
> > +  static bool sPrefCacheInited = false;
> 
> This is not good. What about if the console is used just in workers?

I thought there was always a Console instead in the main thread to receive worker messages,
but I may have misunderstood, or, the main thread one is only fired *after* the worker one?

> I suggest to add a nsContentUtils::DevToolsEnabled() method that do this
> code on main-thread and in workers it uses WorkerPrefs.h.

Done.
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

https://reviewboard.mozilla.org/r/166546/#review177478

::: dom/base/nsContentUtils.cpp:708
(Diff revision 4)
>  
>    Preferences::AddBoolVarCache(&sIsCustomElementsEnabled,
>                                 "dom.webcomponents.customelements.enabled", false);
>  
> +  Preferences::AddBoolVarCache(&sDevToolsEnabled,
> +                               "devtools.enabled");;

double ;

::: dom/console/Console.cpp:1206
(Diff revision 4)
>                          const Sequence<JS::Value>& aData)
>  {
> +  // Make all Console API no-op if DevTools aren't enabled.
> +  if (!nsContentUtils::DevToolsEnabled(aCx)) {
> +    return;
> +  }

Add the same to Console::ProfileMethodInternal
Attachment #8895349 - Flags: review?(amarchesini) → review-
Comment on attachment 8895349 [details]
Bug 1382377 - Make Console API be a no-op until DevTools are opened at least once.

https://reviewboard.mozilla.org/r/166546/#review177480

I would like to see a test. Can you submit a separate patch for it?
Attachment #8895349 - Flags: review- → review+
Assignee: nobody → poirot.alex
Status: NEW → ASSIGNED
Comment on attachment 8901889 [details]
Bug 1382377 - Test console against devtools.enabled pref.

https://reviewboard.mozilla.org/r/173318/#review178906

Thanks.
Attachment #8901889 - Flags: review?(amarchesini) → review+
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/31396f1d727f
Make Console API be a no-op until DevTools are opened at least once. r=baku,jdescottes
https://hg.mozilla.org/integration/autoland/rev/4bb4b46fcc61
Test console against devtools.enabled pref. r=baku
Backed out for mochitest failures on Android, e.g. dom/console/tests/test_bug659625.html:

https://hg.mozilla.org/integration/autoland/rev/e762063a460e6d337e99f7f2f9088145ffdd47b9
https://hg.mozilla.org/integration/autoland/rev/0ee2b3ba9f59e0d5416552e06d2027710ffe64b4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&revision=4bb4b46fcc614934800c108cc66e61afd3b67843&filter-resultStatus=testfailed&filter-resultStatus=busted&filter-resultStatus=exception&filter-resultStatus=retry&filter-resultStatus=usercancel&filter-resultStatus=runnable
Failure log example: https://treeherder.mozilla.org/logviewer.html#?job_id=126764687&repo=autoland

[task 2017-08-29T15:44:32.201076Z] 15:44:32     INFO -  195 INFO None196 INFO TEST-START | dom/console/tests/test_bug659625.html
[task 2017-08-29T15:44:32.201159Z] 15:44:32     INFO -  Buffered messages logged at 15:44:25
[task 2017-08-29T15:44:32.201219Z] 15:44:32     INFO -  197 INFO TEST-PASS | dom/console/tests/test_bug659625.html | Console is empty when test is starting
[task 2017-08-29T15:44:32.201263Z] 15:44:32     INFO -  Buffered messages finished
[task 2017-08-29T15:44:32.201339Z] 15:44:32     INFO -  198 INFO TEST-UNEXPECTED-FAIL | dom/console/tests/test_bug659625.html | Only one event remains in consoleAPIStorage
[task 2017-08-29T15:44:32.201397Z] 15:44:32     INFO -      clearAndCheckStorage@dom/console/tests/test_bug659625.html:21:5
[task 2017-08-29T15:44:32.201444Z] 15:44:32     INFO -      @dom/console/tests/test_bug659625.html:30:3
[task 2017-08-29T15:44:32.201554Z] 15:44:32     INFO -  199 INFO TEST-UNEXPECTED-FAIL | dom/console/tests/test_bug659625.html | uncaught exception - TypeError: storage.getEvents(...)[0] is undefined at clearAndCheckStorage@http://mochi.test:8888/tests/dom/console/tests/test_bug659625.html:23:8
[task 2017-08-29T15:44:32.202065Z] 15:44:32     INFO -  @http://mochi.test:8888/tests/dom/console/tests/test_bug659625.html:30:3
[task 2017-08-29T15:44:32.202135Z] 15:44:32     INFO -      simpletestOnerror@SimpleTest/SimpleTest.js:1652:11
[task 2017-08-29T15:44:32.202668Z] 15:44:32     INFO -  200 INFO TEST-OK | dom/console/tests/test_bug659625.html | took 3056ms
[task 2017-08-29T15:44:32.202748Z] 15:44:32     INFO -  201 INFO None202 INFO TEST-START | dom/console/tests/test_bug978522.html
[task 2017-08-29T15:49:43.392848Z] 15:49:43     INFO -  203 INFO TEST-UNEXPECTED-FAIL | dom/console/tests/test_bug978522.html | Test timed out.
[task 2017-08-29T15:49:43.392909Z] 15:49:43     INFO -      reportError@SimpleTest/TestRunner.js:121:7
[task 2017-08-29T15:49:43.392937Z] 15:49:43     INFO -      TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7
[task 2017-08-29T15:49:43.392972Z] 15:49:43     INFO -  204 INFO TEST-OK | dom/console/tests/test_bug978522.html | took 304754ms
[task 2017-08-29T15:49:43.393019Z] 15:49:43     INFO -  205 INFO None206 INFO TEST-START | dom/console/tests/test_bug979109.html
[task 2017-08-29T15:49:54.834798Z] 15:49:54     INFO -  207 INFO TEST-OK | dom/console/tests/test_bug979109.html | took 5290ms
[task 2017-08-29T15:49:54.834889Z] 15:49:54     INFO -  208 INFO None209 INFO TEST-START | dom/console/tests/test_bug989665.html
[task 2017-08-29T15:49:54.835112Z] 15:49:54     INFO -  210 INFO TEST-OK | dom/console/tests/test_bug989665.html | took 4194ms
[task 2017-08-29T15:50:06.234968Z] 15:50:06     INFO -  211 INFO None212 INFO TEST-START | dom/console/tests/test_consoleEmptyStack.html
[task 2017-08-29T15:50:06.235063Z] 15:50:06     INFO -  213 INFO TEST-OK | dom/console/tests/test_consoleEmptyStack.html | took 4332ms
[task 2017-08-29T15:50:06.235542Z] 15:50:06     INFO -  214 INFO None215 INFO TEST-START | dom/console/tests/test_console_binding.html
[task 2017-08-29T15:55:38.528566Z] 15:55:38     INFO -  216 INFO TEST-UNEXPECTED-FAIL | dom/console/tests/test_console_binding.html | Test timed out.
[task 2017-08-29T15:55:38.528820Z] 15:55:38     INFO -      reportError@SimpleTest/TestRunner.js:121:7
[task 2017-08-29T15:55:38.529107Z] 15:55:38     INFO -      TestRunner._checkForHangs@SimpleTest/TestRunner.js:142:7
Flags: needinfo?(poirot.alex)
Depends on: 1395214
That was because devtools-startup-prefs.js isn't loaded on fennec, fixed that with:
  https://reviewboard.mozilla.org/r/166546/diff/6-7/
I opened bug 1395214 to followup on preferences story.

Green try on android:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=45ba10e4d10fbd5c8e3997ab6404807313927465
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e9156a9ede8e
Make Console API be a no-op until DevTools are opened at least once. r=baku,jdescottes
https://hg.mozilla.org/integration/autoland/rev/c23f8bd95172
Test console against devtools.enabled pref. r=baku
Sometime today, ASAN devtools test chunks started failing like https://treeherder.mozilla.org/logviewer.html#?job_id=127166559&repo=autoland and I can't find an obvious cause to back out, so I'm backing these out to see if the failures go away.
Backout by kwierso@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/9182a041d889
Backed out 2 changesets under suspicion of causing asan devtools failures a=backout CLOSED TREE
This backout didn't fix things, so feel free to reland this whenever you're ready.
Flags: needinfo?(poirot.alex)
Pushed by apoirot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/39432409cedd
Make Console API be a no-op until DevTools are opened at least once. r=baku,jdescottes
https://hg.mozilla.org/integration/autoland/rev/3c7dd192779d
Test console against devtools.enabled pref. r=baku
https://hg.mozilla.org/mozilla-central/rev/39432409cedd
https://hg.mozilla.org/mozilla-central/rev/3c7dd192779d
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
status-firefox57: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: