WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Details
Formatted Diff
Diff
Before the patch.
(116.85 KB, image/png)
2012-10-10 12:21 PDT
,
Mike West
no flags
Details
After the patch.
(111.22 KB, image/png)
2012-10-10 12:21 PDT
,
Mike West
no flags
Details
Patch
(5.24 KB, patch)
2012-10-15 05:03 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Patch
(9.54 KB, patch)
2012-10-15 05:34 PDT
,
Mike West
no flags
Details
Formatted Diff
Diff
Show Obsolete
(2)
View All
Add attachment
proposed patch, testcase, etc.
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
Created
attachment 167601
[details]
Patch
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
Created
attachment 168682
[details]
Patch
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
Created
attachment 168689
[details]
Patch
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.
Top of Page
Format For Printing
XML
Clone This Bug