Closed Bug 1687440 Opened 3 years ago Closed 9 months ago

Debugger tooltip for Date object shows "<prototype>: Date.prototype"

Categories

(DevTools :: Debugger, enhancement, P3)

Firefox 84
enhancement

Tracking

(firefox118 fixed)

RESOLVED FIXED
118 Branch
Tracking Status
firefox118 --- fixed

People

(Reporter: ddascalescu, Assigned: bomsy)

References

(Blocks 1 open bug)

Details

Attachments

(4 files, 3 obsolete files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:84.0) Gecko/20100101 Firefox/84.0

Steps to reproduce:

Debugg some JS code that initializes a Date object

Actual results:

Mousing over that Date variable in the debugger shows "<prototype>: Date.prototype"

Expected results:

Showing a string representation of the date.

Component: Untriaged → General
Product: Firefox → DevTools
Component: General → Debugger

Thanks for reporting!

I can reproduce it.
Adding STR

  1. Go to https://preview-js-test.glitch.me/
  2. Open the debugger
  3. Set a breakpoint on line 4
  4. Reload page
  5. After the breakpoint is hit
  6. Hover over a on line 3

AR
Tooltip shows "<prototype>: Date.prototype"

ER
Tooltip should show the formatted date as well as the object

Attached image image.png

We can render the same data (perhaps using the same Rep components) as the Console panel.

Honza

Severity: -- → S3
Priority: -- → P3

would like to try this one

Sure go ahead. Assigned to you.
Thanks

Assignee: nobody → anzumana.sander

Depends on D151120

Depends on D151235

Attachment #9284482 - Attachment is obsolete: true
Attachment #9284497 - Attachment is obsolete: true
Attachment #9284306 - Attachment is obsolete: true

patch is only waiting for review, I'll try to get to it this week

Assignee: nobody → anzumana.sander

Sorry, there was a problem with the detection of inactive users.

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: anzumana.sander → nobody
Assignee: nobody → hmanilla
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #9342236 - Attachment description: WIP: Bug 1687440 - [devtools] Make the debugger previews consistent with the console → Bug 1687440 - [devtools] Make the debugger previews consistent with the console r=#devtools-reviewers
Pushed by hmanilla@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/954433fb5cc5
[devtools] Make the debugger previews consistent with the console r=devtools-reviewers,nchevobbe
Pushed by hmanilla@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7cad7000bc1c
[devtools] Make the debugger previews consistent with the console r=devtools-reviewers,nchevobbe
Status: ASSIGNED → RESOLVED
Closed: 9 months ago
Resolution: --- → FIXED
Target Milestone: --- → 118 Branch
Flags: needinfo?(hmanilla)

== Change summary for alert #39187 (as of Tue, 01 Aug 2023 12:59:15 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
29% damp custom.jsdebugger.preview.DAMP linux1804-64-shippable-qr e10s fission stylo webrender 395.55 -> 282.78
28% damp custom.jsdebugger.preview.DAMP linux1804-64-shippable-qr e10s fission stylo webrender-sw 389.54 -> 282.22
22% damp custom.jsdebugger.preview.DAMP windows10-64-shippable-qr e10s fission stylo webrender 337.24 -> 262.64
22% damp custom.jsdebugger.preview.DAMP windows10-64-shippable-qr e10s fission stylo webrender-sw 336.73 -> 262.45
19% damp custom.jsdebugger.preview.DAMP macosx1015-64-shippable-qr e10s fission stylo webrender-sw 509.39 -> 414.87
18% damp custom.jsdebugger.preview.DAMP macosx1015-64-shippable-qr e10s fission stylo webrender 484.92 -> 396.92

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=39187

Nicolas: you offered to take a look and check if the improvement is correct or if the test is not properly waiting.

Flags: needinfo?(nchevobbe)

(In reply to Julian Descottes [:jdescottes] from comment #18)

== Change summary for alert #39187 (as of Tue, 01 Aug 2023 12:59:15 GMT) ==

Nicolas: you offered to take a look and check if the improvement is correct or if the test is not properly waiting.

The test only waits for the preview to be displayed: https://searchfox.org/mozilla-central/rev/0058dbdd1c2eb9164e195082d18f3a657f291824/testing/talos/talos/tests/devtools/addon/content/tests/debugger/debugger-helpers.js#368-371

dump("Waiting for the preview popup to show\n");
await waitUntil(() =>
  tokenElement.ownerDocument.querySelector(".preview-popup")
);

But we show it early now, and the ObjectInspector is responsible to fetch the properties and display them.
We should probably wait until we have more than one ObjectInspector node being rendered to accurately represent what the users are experiencing

Flags: needinfo?(nchevobbe)

Thanks for the investigation! On the other hand, it's fine if the test measures when the popup shows, even if it will still take some time to fully initialize. The user feedback is still faster, and that should overall feel faster for the end user.

IMO we don't have to fix the test. Maybe add another metric for the full initialization of the popup, but it seems short enough and might not be useful to track.

(In reply to Julian Descottes [:jdescottes] from comment #20)

Thanks for the investigation! On the other hand, it's fine if the test measures when the popup shows, even if it will still take some time to fully initialize. The user feedback is still faster, and that should overall feel faster for the end user.

IMO we don't have to fix the test. Maybe add another metric for the full initialization of the popup, but it seems short enough and might not be useful to track.

Alright, that makes sense. And I just remembered that we do have a console test for ObjectInspector expanding, so this part is covered

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: