Closed Bug 1247953 Opened 8 years ago Closed 8 years ago

devtools.hud.loglimit.console value does not have effect on restart.

Categories

(DevTools :: General, defect, P3)

defect

Tracking

(firefox48 fixed)

RESOLVED FIXED
Firefox 48
Tracking Status
firefox48 --- fixed

People

(Reporter: jujjyl, Assigned: baku)

References

()

Details

(Whiteboard: [btpp-backlog])

Attachments

(2 files)

STR:

1. Open Firefox, go to about:config
2. Change devtools.hud.loglimit.console to e.g. 20000.
3. Run a page that prints a lot in console to check it works.
4. Close and restart Firefox.
5. Run the same page again.

Observed: The page print output is limited to the default value (1000) instead of the changed value.
When running data:text/html,<script>for(var i =0; i< 2000; i++) console.log(i)</script> if I set devtools.hud.loglimit.console to 2000 I'm seeing all 2000 logs (assuming the console is opened before the page loads).  Do you have a particular page where this isn't working?

If the console is closed while the page loads then only 200 are shown, but that's a limit in the console storage API: https://dxr.mozilla.org/mozilla-central/source/dom/base/ConsoleAPIStorage.js#17.  Possibly that should be tweaked based on the pref, although we also have to worry about how much we are storing for users who never open the developer tools.
Flags: needinfo?(jujjyl)
Filter on TEAPOT-SPLINES.
Priority: -- → P3
Whiteboard: [btpp-backlog]
Attached file a.html
Repro
Flags: needinfo?(jujjyl)
Brian's hunch in comment 1 is correct. In my case, I was debugging a page that prints immediately at page load time, so the console was closed in this scenario. That is very unintuitive, if one doesn't somehow guess that kind of interaction is in play, then it looks as good as broken, like I misunderstood here. Is there a reason to optimize to only store hardcoded(?) 200 most recent log prints instead of 1000 (the default value of devtools.hud.loglimit.console)?
(In reply to Jukka Jylänki from comment #4)
> Brian's hunch in comment 1 is correct. In my case, I was debugging a page
> that prints immediately at page load time, so the console was closed in this
> scenario. That is very unintuitive, if one doesn't somehow guess that kind
> of interaction is in play, then it looks as good as broken, like I
> misunderstood here. Is there a reason to optimize to only store hardcoded(?)
> 200 most recent log prints instead of 1000 (the default value of
> devtools.hud.loglimit.console)?

I don't know if we have data on how much memory it consumes, but one important difference is that the console API storage [0] is storing things even for users who have never opened devtools.  And the when you open up devtools the devtools.hud.loglimit.console restriction is more about frontend performance of the console (in which it unfortunately becomes very slow and has had some improvements as in [1] but still isn't really able to handle a ton of messages at once).

Andrea, what do you think about increasing the 200 message limit in console API storage?  I wonder if existing measurements like https://areweslimyet.com/ would give us useful data on what kind of footprint it adds.

[0]: https://dxr.mozilla.org/mozilla-central/source/dom/base/ConsoleAPIStorage.js#17
[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1237368#c5
Flags: needinfo?(amarchesini)
> frontend performance of the console (in which it unfortunately becomes very
> slow and has had some improvements as in [1] but still isn't really able to
> handle a ton of messages at once).

I see 2 problems here. Maybe we can introduce an iterator that gives you console log 1 by 1.
Would that improve this issue?

> Andrea, what do you think about increasing the 200 message limit in console
> API storage?  I wonder if existing measurements like

What would a better number be? Instead, what about if we try to use the same Console Actor approach on the main-thread?
In the latest landed code, we have 200 items per Console object in workers. That seems a good improvement.
Flags: needinfo?(amarchesini) → needinfo?(bgrinstead)
(In reply to Andrea Marchesini (:baku) from comment #6)
> > frontend performance of the console (in which it unfortunately becomes very
> > slow and has had some improvements as in [1] but still isn't really able to
> > handle a ton of messages at once).
> 
> I see 2 problems here. Maybe we can introduce an iterator that gives you
> console log 1 by 1.
> Would that improve this issue?

I don't think it would.  The problem seems to be frontend jank and in fact we are manually buffering up logs as we receive them so we can process a bunch at once and trim off ones we know won't be displayed to limit the number of reflows.  We are working on an updated version of the output frontend that I hope will have better perf though (will be running it through talos to confirm).

> > Andrea, what do you think about increasing the 200 message limit in console
> > API storage?  I wonder if existing measurements like
> 
> What would a better number be? Instead, what about if we try to use the same
> Console Actor approach on the main-thread?
> In the latest landed code, we have 200 items per Console object in workers.
> That seems a good improvement.

The suggestion in Comment 4 is to increase the global limit to 1000 to match the current number we show in the frontend.

Interesting, so we are storing up to 200 *per worker* now?  Are you suggesting possibly storing a max per window instead of a global max?  That would be nice (and make it more consistent for how much shows up in an individual tab's toolbox), but would potentially cause us to store a lot more messages in total than bumping up the current limit.

I don't have a good sense of how much of an overhead storing extra messages adds.  Of course I'd like to store as many as possible but since this affects all users (even those who haven't opened devtools) we need to balance that.
Flags: needinfo?(bgrinstead) → needinfo?(amarchesini)
> Interesting, so we are storing up to 200 *per worker* now?  Are you
> suggesting possibly storing a max per window instead of a global max?

We are storing 200 ConsoleEvent per ID. Dedicated workers use the same ID of their parent window.
I think we can increase this limit, also because if we run out of memory, when memory-pressure notification is received, we empty the storage completely.
Flags: needinfo?(amarchesini)
Assignee: nobody → amarchesini
Attachment #8742219 - Flags: review?(bgrinstead)
Comment on attachment 8742219 [details] [diff] [review]
console_limit.patch

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

Works for me.  Jukka, do you think this will be enough to resolve your bug report, taking into account that it won't match modified prefs for the frontend?
Attachment #8742219 - Flags: review?(bgrinstead)
Attachment #8742219 - Flags: review+
Attachment #8742219 - Flags: feedback?(jujjyl)
Comment on attachment 8742219 [details] [diff] [review]
console_limit.patch

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

Yeah, I suppose it's good. I think the original bug report was more about mistaking the pref to not have any effect at all, since the UX is a bit unintuitive that I didn't know the console didn't save as much when it's closed. Thanks for working on this!
Attachment #8742219 - Flags: feedback?(jujjyl) → feedback+
https://hg.mozilla.org/mozilla-central/rev/894e3c1ce799
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
I have reproduced this bug with Nightly 48.0a1 (2016-04-20) on Windows 7, 64 Bit!

This bug's fix is verified with Latest Developer Edition, Beta.


Build ID   20160727004019
User Agent Mozilla/5.0 (Windows NT 6.1; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0


Build ID   20160714050942
User Agent Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:48.0) Gecko/20100101 Firefox/48.0
Just to point this out: In FF 51.0.1 (64bit) Windows 10.

The default value of devtools.hud.loglimit.console is 1000
If you set it up to 2000 you get 2000
If you set it up to 3000 you get 1000
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.