RESOLVED FIXED Bug 97980
Console messages containing long URLs should cut at some reasonable length.
https://bugs.webkit.org/show_bug.cgi?id=97980
Summary Console messages containing long URLs should cut at some reasonable length.
Mike West
Reported 2012-09-30 12:42:29 PDT
From a user report: "Any console feedback about a resource loaded using a data URI echoes the entire data URI to the javascript console, which can really slow things down, and creates a huge amount to scroll back through."
Attachments
Patch (3.13 KB, patch)
2012-10-08 13:57 PDT, Mike West
no flags
Before the patch. (116.85 KB, image/png)
2012-10-10 12:21 PDT, Mike West
no flags
After the patch. (111.22 KB, image/png)
2012-10-10 12:21 PDT, Mike West
no flags
Patch (5.24 KB, patch)
2012-10-15 05:03 PDT, Mike West
no flags
Patch (9.54 KB, patch)
2012-10-15 05:34 PDT, Mike West
no flags
Mike West
Comment 1 2012-09-30 12:43:07 PDT
CCing some inspector-folk.
Alexey Proskuryakov
Comment 2 2012-10-01 10:49:56 PDT
Please keep a way to get to full URL though (perhaps a shortened visible link that points to actual URL?)
Mike West
Comment 3 2012-10-01 10:58:40 PDT
Right, I agree. I certainly didn't mean "cut" in the sense of dropping the data. I was thinking '...' which, when clicked on, would expand to display the whole URL, or something similar.
Mike West
Comment 4 2012-10-08 13:57:40 PDT
Mike West
Comment 5 2012-10-08 14:03:16 PDT
Hey Pavel, Yury. I'd love to write a test for this, but I'm not entirely sure how. I could check the width of a really long URL to ensure that it's maxed out at 40%, but much more than that would require diving into pixel tests (which all the 'fast/css/text-overflow-ellipsis-*' tests seem to do). I'm not sure that's a good idea for the inspector. WDYT? Alexey: To your point, the current patch doesn't throw away URL data. Hovering over the link will display the URL from the link's 'title' attribute, and all the detail you like is available either by clicking on the link to take you directly to the resource, or by right-clicking and choosing one of the link-related options from the context menu. Does that address your concern?
Build Bot
Comment 6 2012-10-08 17:49:28 PDT
Comment on attachment 167601 [details] Patch Attachment 167601 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14207696 New failing tests: http/tests/workers/terminate-during-sync-operation.html
Pavel Feldman
Comment 7 2012-10-10 12:00:06 PDT
Could you provide a screenshot with the patch applied?
Mike West
Comment 8 2012-10-10 12:21:09 PDT
Created attachment 168052 [details] Before the patch.
Mike West
Comment 9 2012-10-10 12:21:32 PDT
Created attachment 168053 [details] After the patch.
Mike West
Comment 10 2012-10-10 12:21:51 PDT
(In reply to comment #7) > Could you provide a screenshot with the patch applied? Attached to the bug.
Pavel Feldman
Comment 11 2012-10-15 04:29:33 PDT
Comment on attachment 167601 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=167601&action=review > Source/WebCore/inspector/front-end/ResourceUtils.js:172 > + classes += " linkifiedURL"; No need for the new class, you could use webkit-html-external-link, webkit-html-resource-link classes instead. > Source/WebCore/inspector/front-end/inspector.css:1023 > +#console-messages a.linkifiedURL { I wonder if we should explicitly trimMiddle instead and limit the url to say 200 characters. WDYT? You should also assign a title (tooltip) for the potentially trimmed url.
Mike West
Comment 12 2012-10-15 04:35:57 PDT
(In reply to comment #11) > > Source/WebCore/inspector/front-end/inspector.css:1023 > > +#console-messages a.linkifiedURL { > > I wonder if we should explicitly trimMiddle instead and limit the url to say 200 characters. WDYT? You should also assign a title (tooltip) for the potentially trimmed url. Hrm. Good suggestion. Trimming the middle would leave the filename visible in the common case... I'll take a stab at that.
Mike West
Comment 13 2012-10-15 05:03:33 PDT
Mike West
Comment 14 2012-10-15 05:04:43 PDT
(In reply to comment #13) > Created an attachment (id=168682) [details] > Patch This patch trims the URL down to 150 characters. That still looks like a lot, honestly. The nice thing about this approach, however, is that I can write a simple layout test so you can see the result too. :) WDYT?
Build Bot
Comment 15 2012-10-15 05:25:52 PDT
Comment on attachment 168682 [details] Patch Attachment 168682 [details] did not pass mac-ews (mac): Output: http://queues.webkit.org/results/14291668 New failing tests: inspector/styles/inject-stylesheet.html
Mike West
Comment 16 2012-10-15 05:34:59 PDT
Mike West
Comment 17 2012-10-15 05:38:23 PDT
(In reply to comment #16) > Created an attachment (id=168689) [details] > Patch Sorry, I meant to just carry the review over. Didn't mean to bug you again. :)
WebKit Review Bot
Comment 18 2012-10-15 14:00:29 PDT
Comment on attachment 168689 [details] Patch Clearing flags on attachment: 168689 Committed r131353: <http://trac.webkit.org/changeset/131353>
WebKit Review Bot
Comment 19 2012-10-15 14:00:34 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.