From MozillaWiki
Jump to: navigation, search


  • Scribe: James
  • Chair: Honza

JSTracer Demo (Alex)

  • JavaScript Tracing should appear in latest nightly build. It's behind `Devtools.debugger.features.javascript-tracing` pref that you have to manually turn to `true`
  • Watchout for a new icon on the left of the Pause button in the Debugger panel. It will log to the Console panel by default
  • If you are getting any performance issue with this mode, remember that you can right click on this icon in order to force logging to your terminal instead.



  • Dennis: I used this last week for a diagnosis, and it was really helpful. On a heavy site there was so much logging the browser hung when using the console output. Would really like a key shortcut to start/stop tracing to avoid invoking event handlers when moving the mouse. Might also help with perf since it would be easy to trace less. But already it's helped me get unstuck.
  • Alex: That makes sense. I'll try to find an empty keyboard shortcut!
  • Tom: Looks like exactly what I was hoping for. Might be useful to be able to log to a file?
  • Alex: Is it OK to create a temp file and log the path to stdout? [yes]
  • Tom: Would be good to have filtering, but we can do that in an editor of course. Does this show what triggered the code? Or just the lines of code?
  • Alex: The latter. I don't know if we have this information. We display which type of js engine we're using, which isn't so relevant for webcompat, but is relevant to performance.
  • Dennis: To work around the event handling stuff, I added a breakpoint on the code.
  • Alex: We could show the stack for the first call, and then the following lines are all called from that point.
  • Tom: If it has a perf impact, we could make it optional.
  • Alex: Could be memory overhead from keeping the stack. I should ask for more feedback once more people have tried it. When working on this I was thinking that it could be exposed to js as console.startTracing to give fine control of when you start and stop the tracing. We could expose it as a new kind of breakpoint. Might not be useful if you are just trying to figure out what's going on.
  • Tom: console.startTrace would be helpful for js overrides. Not very important, but would probably be used.
  • Alex: Console API is unspecified. Might be a problem to add new things.
  • Dennis: That would replace the need for keyboard shortcuts for my diagnosis.
  • jgraham: Making it work like a breakpoint might be better rather than adding to the console API
  • Alex: console API is useful for e.g. mochitests, but that could be Chrome-only. Last feature I had in mind was for tracing to filter on current file. So we could restrict to a specific module/ URL. Debugger UI might allow you to pick the context.
  • Tom: Limiting to only files that are open in the debugger might help, or use existing ignore lists for libraries.
  • Dennis: With bundled code, just limiting on the current file doesn't help much. So not high priority for me.
  • Alex: might be more relevant to regular web developers.

Google Drive offline mode (SV)

As discussed with Honza and Dennis:

Google drive requires an `add-on` that is specific just for Chromium browsers, in order to be used offline and since docs/sheets etc. relies on the Gdrive we are not able to test these as well.

  • Raul: Chrome does not need the `add-on` to be installed, it works without it. Edge needs the `add-on` to be installed, which can be installed, and the feature is available once the `add-on` is installed. However, for Firefox, with the default UA, does not have the "Offline" feature for Gdrive, following the above link. Changing the UA in Firefox to either Edge of Chrome (it is importat to be signed in prior to changing the UA) shows the `feature` in the settings of the account. Once you try to enable it, it prompts a pop-up that redirects to the installment page of the add-on if you click on the `Install` button, but there is no option available to install the add-on, as it is specific for Chromium based browsers.
  • Honza: Is it broken?
  • Dennis: It's interesting. Not surprising that the Chrome store doesn't work in Firefox. Extension is a lot of minified js. Appears to shim a storage API using WebExtensions storage API. Also shipping shims for many js features [which are now common]. Redirection to extension seems to be based on feature detection, so maybe possible to understand which APIs are required. Doesn't appear to use WebExtensions API that we don't support. In theory it might be possible to port the extension to Firefox. Looks like it ought to work. Can't just ship a UA override since we can't even sign in in that case. Block things that don't look enough like real Chrome. Depends how much time we want to spend on this. Likely to take a day+ to understand what's going on.
  • Honza: Sounds like a good experiment, but I also don't know how much time to invest.
  • Tom: Hard to know if it's a good idea without insight from Google. Might be good to ask first. Maybe tracer would help with diagnosis here?
  • Dennis: Goal of more diagnosis would just be to understand why it doesn't work. Unrealistic to make it work at the moment. Even if we supported all the missing APIs there's a chance it wouldn't be enabled in Firefox anyway. Only realistic outcome is better understanding of need for APIs.
  • James: The fact that you need to install extra extensions in other Chromium browsers is pretty unique. We should write up what we figure out and make available for Kush, overholt, bobby. It's very clear that it's not a techincal problem, but a business decision.
  • Tom: If we're not going to get anything out of it, it's hard to justify spending time on it.
  • Honza: We can write up what we know and then see if there's interest in getting more analysis of the technical side.
  • Dennis: I can work on this, but not this week.
  • Dennis: Chrome extension code:
  • Ksenia: I can look.
  • Tom: I can also help. We can have a call or a thread.
  • Dennis: I'll start a thread and explain what I already figured out.