It would be nice to track a couple of quick ux wins that we can land in Nightly, which could help us grow the user base and test web replay internally and with partners. - "jump to here" button in the console - "paused here" badge in the console - "reload and record" button in the toolbar - web replay submenu contextmenu
Brian, I can imagine a front-end solution for the pause here badge where we set it when the user jumps and clear it when the debugger resumes. I think we could do something interesting in the server as well, where on pause we check if we're paused at a console message and send that down with the pause packet. What do you think? The "reload and record" button is slightly new behavior because we're changing the tab's mode as opposed to creating a new tab. Is that possible? How much work is that to do?
I think some additional UX items would be: - add telemetry for when a recording starts - add telemetry for each new buttons - add a "save" function to the "reload and record" button. When the user clicks the button during a recording session, it should show the "save recording" prompt.
(In reply to Jason Laster [:jlast] from comment #1) > Brian, I can imagine a front-end solution for the pause here badge where we > set it when the user jumps and clear it when the debugger resumes. I think > we could do something interesting in the server as well, where on pause we > check if we're paused at a console message and send that down with the pause > packet. What do you think? I think it would be easier to track this in the frontend. Tracking this in the server would require some new logic in the replaying process to tell when we are paused at an execution point that coincides with a console message. This shouldn't be that hard, but the main advantage AFAICT is that if the user arrives at a console message via a method other than the jump button (i.e. just stepping around in the code), we would still be able to show the paused badge. I don't know if that would be a nice/important feature, though. > The "reload and record" button is slightly new behavior because we're > changing the tab's mode as opposed to creating a new tab. Is that possible? > How much work is that to do? Yeah, this is new behavior. I don't think it will be a huge amount of work but will start on it today to either get it done or learn more about its complexity.
> I think it would be easier to track this in the frontend This sounds like a good MVP option too.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/8b650bb26b71 Add paused and jump badge to console api messages r=jlast
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/edc506b37439 Add a reload and record button. r=lsmyth
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/e1fb734d457b Revert "Backed out changeset edc506b37439 for failing at /browser_toolbox_options_disable_buttons.js on a CLOSED TREE"
Just fixed the test.
QA Contact: bhackett1024
Some issues with the `webconsole/jump.svg` icon: - missing the license comment (recently confirmed with :pbro that we should use it for each SVG icon); - designed at 18px but rendered at 14px which is bound to be blurry on non-retina displays; - could be optimized (there's some Sketch export cruft in there); - hardcoded color (we should use context-fill + pass a color from the CSS, maybe `var(--object-color)` like we did for the navigation marker.
You need to log in before you can comment on or make changes to this bug.