Skip to content
This repository has been archived by the owner on Jan 11, 2023. It is now read-only.

UI for XHR Breakpoints #6934

Merged
merged 17 commits into from
Oct 20, 2018
Merged

UI for XHR Breakpoints #6934

merged 17 commits into from
Oct 20, 2018

Conversation

AnshulMalik
Copy link
Contributor

Fixes Issue: #5255

Summary of Changes

  • First version of xhr, we can say "pause if the url contains a given string"
  • We can leave the box empty if we want to pause for any request.

Screenshots/Videos (OPTIONAL)

ezgif com-optimize-2

@@ -497,6 +497,10 @@ expressions.errorMsg=Invalid expression…
expressions.label=Add watch expression
expressions.accesskey=e

xhrBreakpoints.header=XHR Breakpoints
xhrBreakpoints.placeholder=Break when url contains
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think URL should be uppercase

@@ -497,6 +497,10 @@ expressions.errorMsg=Invalid expression…
expressions.label=Add watch expression
expressions.accesskey=e

xhrBreakpoints.header=XHR Breakpoints
xhrBreakpoints.placeholder=Break when url contains
xhrBreakpoints.label=Add xhr breakpoint
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

XHR was uppercase in the previous string

@nchevobbe
Copy link
Member

That's great @AnshulMalik !
I find that being able to break on URL matching is also super interesting (we could then even have some context menu entries/buttons in the netmonitor to allow adding XHR breakpoints from there).

The only thing that puzzles me a bit is the "leave input empty to break on all XHR".
It could be better, because here, we have a list of matching input, so you could have 1 empty input (match all) and another one for a specific URL, which is a bit weird.
My gut feeling is that we should make break on all XHR the default, and then allow for some matching.

▼ XHR breakpoints
⚪️ Break on all XHR
🔘 Break when URL matches    ➕
       facebook.com
       foo/bar

or something better, but that a clear distinction between breaking on everything and allowing for URL matching.

@AnshulMalik
Copy link
Contributor Author

@nchevobbe Yeah, that sounds more practical.

Since the designs were not yet ready, so I went ahead with what chrome does.

@darkwing
Copy link
Contributor

darkwing commented Sep 6, 2018

When @AnshulMalik casually submits a PR for an incredibly awesome feature:

giroud-slide

I'll take an in-depth look at this tomorrow. Obviously this is awesome but wasn't well spec'd out by us so there will likely be lots of feedback. In the mean time...this is amazing! Thank you! 💯

@darkwing darkwing changed the title [WIP] UI for XHR Breakpoints UI for XHR Breakpoints Sep 6, 2018
Copy link

@flodolo flodolo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

String-wise it looks good, thanks for updating it.

Letting code review to the actual devs ;-)

@darkwing
Copy link
Contributor

A few behavioral things I'm seeing:

  1. The "+" button in the XHR breakpoints header doesn't do anything.
  2. Toggling the header open focuses on the input; not sure we need that.
  3. The "x" (close) button for items needs to be shifted a few pixels to the right/end

These are all minor things; I think if you get time to clean this up a bit (i.e. removing commented code), we can try to land something. Great work so far @AnshulMalik !

@AnshulMalik
Copy link
Contributor Author

Hey @darkwing, thanks for the comments, here my my thoughts:

  1. It's the same as watch expressions, add one xor bp, and then click in the editor, so now if you want to add another xhr bp, you need to click "+" to get the input box.

  2. This is strange, since toggling the header does toggle hide/show the panel.

  3. Working on it :)

@darkwing
Copy link
Contributor

Adding in an older mockup from @violasong:

xhrbreakpoints

Obviously we dont' need to do all of this at once. It might be nice in this first PR if we can add the GET/POST dropdown for adding the breakpoint though.

@digitarald
Copy link
Contributor

Just to clarify: The mockup should not inform the UI or requirements for this first implementation. Goal is a simple UI, similar to existing XHR breakpoint implementations (aka Chrome). We will iterate on the UI in the future, @mcroud is working taking over the design work.

Just to re-iterate the basic requirements:

  1. allow pausing on any resource
  2. allow pausing on responses matching a URL pattern

Do they make sense?

@darkwing
Copy link
Contributor

darkwing commented Oct 2, 2018

Per @digitarald's comment, the only thing missing is a "pause on all XHRs"; maybe in the short term we can simply add a checkbox like we do for "Pause on Exceptions". Up for it @AnshulMalik ? This is sooooooo close!

@digitarald
Copy link
Contributor

the only thing missing is a "pause on all XHRs"; maybe in the short term we can simply add a checkbox like we do for "Pause on Exceptions".

Chrome offers a checkbox for this, so maybe. The alternative is would be an XHR breakpoint without a URL filter (which Chrome has before I think).

How are empty XHR breakpoints treated in the current solution?

@AnshulMalik
Copy link
Contributor Author

Okay, we can have a checkbox for pause on all xhr,
@digitarald currently, if you hit enter on empty string, it will work as pause on all xhr breakpoints

@digitarald
Copy link
Contributor

@digitarald currently, if you hit enter on empty string, it will work as pause on all xhr breakpoints

Looks like the latest behavior on Chrome removes empty XHR breakpoints.

@@ -513,6 +513,14 @@ expressions.label=Add watch expression
expressions.accesskey=e
expressions.key=CmdOrCtrl+Shift+E

xhrBreakpoints.header=XHR Breakpoints
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a note here.

# LOCALIZATION NOTE (expressions.errorMsg): Error text for expression
# input element
expressions.errorMsg=Invalid expression…
expressions.label=Add watch expression
expressions.accesskey=e
expressions.key=CmdOrCtrl+Shift+E

# LOCALIZATION NOTE (xhrBreakpoints): The pause on any xhr breakpoints headings
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The string ID referenced in the comment should be xhrBreakpoints.header, also XHR (uppercase) in the note itself for consistency.

@darkwing
Copy link
Contributor

I've rebased and fixed a header issue. @AnshulMalik Would you be able to make a quick mochitest or two for this functionality? i.e. add an xhr breakpoint and ensure it pauses when hit?

@AnshulMalik
Copy link
Contributor Author

Created a PR here, to allow the functionality to work firefox-devtools/devtools-core#1098

@darkwing
Copy link
Contributor

darkwing commented Oct 11, 2018

Current to do:

  • Tests
  • Localization changnes
  • Update package.json's version for devtools-core

const dbg = await initDebugger("doc-xhr.html");
await waitForSources(dbg, "fetch.js");
await dbg.actions.setXHRBreakpoint("doc", "GET");
debugger;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this supposed to be here? Shouldn't the pause happen from setting the breakpoint?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, it should not be here

@darkwing
Copy link
Contributor

OK, cool, manually tested and this is totally in the right direction. Yay!

A few things:

  1. When I add a create an XHR breakpoint (for example "fetch"), then click "Pause on any", then click "Pause on any" again, the "fetch" XHR breakpoint disappears. Ideally this wouldn't have any effect on XHR breakpoints added by the user; it would just disable them.

  2. We need to change the label to "Pause on any URL"

  3. How difficult would it be to persist XHR breakpoint strings? i.e. store them in prefs so that when we refresh the page, the breakpoint is still there?

  4. How difficult would it be to add a green highlight to the currently-broken-on XHR breakpoint? This can definitely come late but worth asking.

@AnshulMalik
Copy link
Contributor Author

1-3 are present in this commit.

  1. This one is interesting, it won't be hard, but would be a nice to have.

@darkwing darkwing merged commit 9fe51cc into firefox-devtools:master Oct 20, 2018
@DPX-designer
Copy link

Here are the final mockups for light and dark mode complete with the agreed "pause" terminology.

Light mode:
https://mozilla.invisionapp.com/share/VTOMJAC7EH5#/326071897_XHR-Breakpoints_2

Dark mode:
https://mozilla.invisionapp.com/share/AWOP2TNUJ2V#/326848311_XHR-Breakpoints_2_Dark

darkwing pushed a commit that referenced this pull request Oct 23, 2018
egdbear pushed a commit to egdbear/debugger.html that referenced this pull request Oct 23, 2018
@AnshulMalik AnshulMalik deleted the xhr branch December 30, 2018 21:16
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants