Bug 114317 - ContentSecurityPolicy::logToConsole should include line/column number and source location
Summary: ContentSecurityPolicy::logToConsole should include line/column number and sou...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Web Inspector (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Devin Rousso
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-04-09 16:14 PDT by Joseph Pecoraro
Modified: 2019-04-23 13:41 PDT (History)
11 users (show)

See Also:


Attachments
test case (552 bytes, text/html)
2015-11-20 13:22 PST, Brian Burg
no flags Details
Patch (4.26 KB, patch)
2019-02-14 11:56 PST, Devin Rousso
no flags Details | Formatted Diff | Diff
Patch (7.04 KB, patch)
2019-03-14 15:03 PDT, Devin Rousso
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Pecoraro 2013-04-09 16:14:13 PDT
ContentSecurityPolicy's security ConsoleMessages should include a column number alongside the line number. If the Web Inspector wants to jump to a specific place in source code it will need both to jump to an accurate place.
Comment 1 Radar WebKit Bug Importer 2013-04-09 16:14:43 PDT
<rdar://problem/13614617>
Comment 2 Brian Burg 2015-11-20 13:22:39 PST
Created attachment 265985 [details]
test case
Comment 3 Brent Fulgham 2016-03-18 13:24:13 PDT
Dan: Did you do anything to address this in your various CSP changes? Otherwise, John should try to attack this soon.
Comment 4 Daniel Bates 2016-03-19 16:17:15 PDT
(In reply to comment #3)
> Dan: Did you do anything to address this in your various CSP changes?

No.
Comment 5 John Wilander 2016-03-21 12:11:22 PDT
Re-assigning to Daniel Bates since he is refactoring this code any way.
Comment 6 Joseph Pecoraro 2019-02-14 11:18:50 PST
TextPostition is used above this which has an m_line and m_column. Might be easy.
Comment 7 Devin Rousso 2019-02-14 11:56:51 PST
Created attachment 362044 [details]
Patch
Comment 8 Joseph Pecoraro 2019-02-14 11:58:35 PST
Comment on attachment 362044 [details]
Patch

I think this needs a test, otherwise I'd have done the same thing myself! There is a test case attached to the bugzilla bug.
Comment 9 Daniel Bates 2019-02-14 12:12:30 PST
Comment on attachment 362044 [details]
Patch

I think this patch will improve some violations, but I don’t think this will improve much. The problem is that we may not have source information at all. Last I recall source information is only available during script execution and at parse time. Subresource loads tend to be scheduled outside these Windows. Prove me wrong, please!
Comment 10 Daniel Bates 2019-02-14 12:18:08 PST
I think I have a partial, likely outdated, patch for this with a boat load of tests. That’s why this bug is assigned to me :) unassigning and please take take it! Why do I have a boat load tests: I seem to recall under testing of log messsages. I will post once I get to my computer and assuming my memory is correct :D. Worst case, I have a boat load of tests for some other bug. Definitely have a boat load of something.
Comment 11 Devin Rousso 2019-03-14 15:03:10 PDT
Created attachment 364694 [details]
Patch
Comment 12 WebKit Commit Bot 2019-04-23 13:41:03 PDT
Comment on attachment 364694 [details]
Patch

Clearing flags on attachment: 364694

Committed r244563: <https://trac.webkit.org/changeset/244563>
Comment 13 WebKit Commit Bot 2019-04-23 13:41:05 PDT
All reviewed patches have been landed.  Closing bug.