Torn-off developer tools (in separate window) have no indication of which page they're targeting

VERIFIED FIXED in Firefox 49

Status

DevTools
Framework
VERIFIED FIXED
4 years ago
a month ago

People

(Reporter: bz, Assigned: jryans)

Tracking

unspecified
Firefox 49

Firefox Tracking Flags

(firefox49 verified)

Details

MozReview Requests

Submitter Diff Changes Open Issues Last Updated
Loading...
Error loading review requests:

Attachments

(3 attachments)

STEPS TO REPRODUCE:

1)  Open developer tools.
2)  Click the little "Show in separate window" icon in the top right of the
    devtools, to the left of the little "x".

EXPECTED RESULTS: Developer tools torn off into a new window that has some indication of which page it's targeting.

ACTUAL RESULTS: There is no such indication in the new window.
For comparison, DOM inspector shows the url of the thing being inspected.
Summary: Torn-off developer tools have no indication of which page they're targeting → Torn-off developer tools (in separate window) have no indication of which page they're targeting
Created attachment 8512808 [details]
Screen Shot 2014-10-28 at 10.05.50 AM.png

Looks like the title of the window is "<panel> - <url>" to me. I think it would be an improvement to make it "<panel> - <title> - <url>" or even simply "<panel> - <title>".

What am I missing?
Ah, so it is.  I completely missed that; I guess I habitually ignore window titlebars.  :(
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → INVALID
(In reply to Nick Fitzgerald [:fitzgen] from comment #2)
> Created attachment 8512808 [details]
> Screen Shot 2014-10-28 at 10.05.50 AM.png
> 
> Looks like the title of the window is "<panel> - <url>" to me. I think it
> would be an improvement to make it "<panel> - <title> - <url>" or even
> simply "<panel> - <title>".

The <panel> portion is redundant, since the section headers right below already show what panel is selected. I agree that we should put the title of the webpage in the window title in front of the URL.
Status: RESOLVED → REOPENED
OS: Mac OS X → All
Hardware: x86 → All
Resolution: INVALID → ---
Status: REOPENED → NEW
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #4)
> (In reply to Nick Fitzgerald [:fitzgen] from comment #2)
> > Created attachment 8512808 [details]
> > Screen Shot 2014-10-28 at 10.05.50 AM.png
> > 
> > Looks like the title of the window is "<panel> - <url>" to me. I think it
> > would be an improvement to make it "<panel> - <title> - <url>" or even
> > simply "<panel> - <title>".
> 
> The <panel> portion is redundant, since the section headers right below
> already show what panel is selected. I agree that we should put the title of
> the webpage in the window title in front of the URL.

I think it is useful when Cmd+Tab'ing on OSX where you can only see the icon + window title. It differentiates the tools window from the browser window. Not sure if other OSs are similar.
Note bug 1224302 -- we've now gone to showing the title but not the url.
(Assignee)

Comment 7

2 years ago
Any consensus on what we *should* show?  The undocked page toolbox currently shows:

<panel> - <title>

however in cases where we don't have the title (workers), we might show:

<panel> - <url>

Should we always should URL?  If so, is the title there too?
Flags: needinfo?(hholmes)
Flags: needinfo?(bgrinstead)
(Assignee)

Updated

2 years ago
See Also: → bug 1224302
We could potentially do something to the actual tab in the browser, like displaying the wrench on top of the favicon like we do with the sound-playing icon.
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7)
> Any consensus on what we *should* show?  The undocked page toolbox currently
> shows:
> 
> <panel> - <title>
> 
> however in cases where we don't have the title (workers), we might show:
> 
> <panel> - <url>
> 
> Should we always should URL?  If so, is the title there too?

I think showing <panel> is redundant. I think <title> — <url> should suffice.
Flags: needinfo?(hholmes)
<title> - <url> is still ambiguous for developers who may have a page open in multiple tabs exhibiting various states.
> We could potentially do something to the actual tab in the browser

That wouldn't help much in my case because the browser window may not even be visible (hidden behind other windows, on a different virtual desktop, etc).
I think "DevTools - <url>" would be nice since you can still tell it's devtools when windowing in the OS as in Comment 5, but it gets rid of the redundant information about selected panel.  And it will go back to showing the URL.  I didn't mean to change it to <title> in Bug 1211017, that was intended only for web/service worker toolboxes.
Flags: needinfo?(bgrinstead)
(In reply to (Unavailable until 3-7) Brian Grinstead [:bgrins] from comment #12)
> I think "DevTools - <url>"

Although it should be "Developer Tools" instead of "DevTools" to match other strings in the UI (like in options panel)

Comment 14

2 years ago
Perhaps we could also display a wrench on every tab that has developer tools opened in the tabbar ? That would help spotting the debugged tab faster.
(Assignee)

Updated

2 years ago
Assignee: nobody → jryans
Status: NEW → ASSIGNED
Component: Developer Tools → Developer Tools: Framework
Created attachment 8748484 [details]
MozReview Request: Bug 1090380 - Show target title and URL in toolbox title. r=bgrins

Review commit: https://reviewboard.mozilla.org/r/50315/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/50315/
Attachment #8748484 - Flags: review?(bgrinstead)
Attachment #8748485 - Flags: review?(bgrinstead)
Created attachment 8748485 [details]
MozReview Request: Bug 1090380 - Set a basic target name for workers. r=bgrins

Review commit: https://reviewboard.mozilla.org/r/50317/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/50317/
Comment on attachment 8748484 [details]
MozReview Request: Bug 1090380 - Show target title and URL in toolbox title. r=bgrins

https://reviewboard.mozilla.org/r/50315/#review47247
Attachment #8748484 - Flags: review?(bgrinstead) → review+
Comment on attachment 8748485 [details]
MozReview Request: Bug 1090380 - Set a basic target name for workers. r=bgrins

https://reviewboard.mozilla.org/r/50317/#review47249

::: devtools/client/framework/target.js:739
(Diff revision 1)
>    get isTabActor() {
>      return true;
>    },
>  
> +  get name() {
> +    return "Worker";

I think this is the same target that's used for service workers.  It's probably OK since Worker is generic, but it'd also be nice to distinguish between service workers / shared workers / web workers (I don't know how easy that is to do from the Target though).
Attachment #8748485 - Flags: review?(bgrinstead) → review+
https://reviewboard.mozilla.org/r/50317/#review47249

> I think this is the same target that's used for service workers.  It's probably OK since Worker is generic, but it'd also be nice to distinguish between service workers / shared workers / web workers (I don't know how easy that is to do from the Target though).

Yes, it is the same, so they will all show "Worker" in the title for now.  Actually, I tried to wire up the real type first, just like you're suggesting, but it was complicated than I wanted to tackle at the moment.  We can improve this later on if someone wants it.

Comment 24

2 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c959c761aa4f
https://hg.mozilla.org/mozilla-central/rev/98730e9d1455
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago2 years ago
status-firefox49: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 49
(Assignee)

Updated

2 years ago
Blocks: 1224302
See Also: bug 1224302
I have reproduced this bug with Nightly 36.0a1 (2014-10-28) on Linux Mint, 64 Bit !

The Bug's fix verified on Latest Aurora 49.0a2 .

Build ID 	20160708004052
User Agent 	Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0

Updated

2 years ago
Status: RESOLVED → VERIFIED
status-firefox49: fixed → verified

Updated

a month ago
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.