Debugger tooltip for Date object shows "<prototype>: Date.prototype"
Categories
(DevTools :: Debugger, enhancement, P3)
Tracking
(firefox118 fixed)
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.
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
•
|
||
Thanks for reporting!
I can reproduce it.
Adding STR
- Go to https://preview-js-test.glitch.me/
- Open the debugger
- Set a breakpoint on line 4
- Reload page
- After the breakpoint is hit
- Hover over
a
on line 3
AR
Tooltip shows "<prototype>: Date.prototype"
ER
Tooltip should show the formatted date as well as the object
Comment 2•4 years ago
|
||
We can render the same data (perhaps using the same Rep components) as the Console panel.
Honza
Assignee | ||
Updated•4 years ago
|
Assignee | ||
Comment 4•3 years ago
|
||
Sure go ahead. Assigned to you.
Thanks
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment hidden (off-topic) |
Comment 10•3 years ago
|
||
patch is only waiting for review, I'll try to get to it this week
Comment 11•3 years ago
|
||
Sorry, there was a problem with the detection of inactive users.
Comment 12•2 years ago
|
||
The bug assignee is inactive on Bugzilla, so the assignee is being reset.
Assignee | ||
Comment 13•2 years ago
|
||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Comment 15•2 years ago
|
||
Backed out changeset 954433fb5cc5 (Bug 1687440) for causing failures in browser_dbg-preview-frame.js CLOSED TREE
Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&collapsedPushes=842382&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&searchStr=dt3&revision=954433fb5cc5cd929f405f044d1f7d827eaced66&selectedTaskRun=bLGt0HAKRXaam2EzMY-WXQ.0
This started to fail quite frequently as seen in this range
Log: https://treeherder.mozilla.org/logviewer?job_id=423768310&repo=autoland&lineNumber=10197
Backout: https://hg.mozilla.org/integration/autoland/rev/d03615dc9504c50f6a54e5deb1d66d59b482def5
Comment 16•2 years ago
|
||
Comment 17•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Comment 18•2 years ago
|
||
== 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.
Comment 19•2 years ago
|
||
(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
Comment 20•2 years ago
|
||
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.
Comment 21•2 years ago
|
||
(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
Description
•