Include a secure lock indicator in the domain column This keeps the data in the table relatively compact but provides a useful indicator (was the request secure (https/wss) / insecure).
<rdar://problem/34070883>
Created attachment 325860 [details] [IMAGE] Before
Created attachment 325861 [details] [IMAGE] After
Created attachment 325862 [details] [IMAGE] Mixed Content
Created attachment 325863 [details] [PATCH] Proposed Fix
Created attachment 325864 [details] [IMAGE] Edge Case - Failure on https Adding an image for a failure to show that the lock icon is still gray and not red. I think a red lock would be bad, since it might indicate something else. I do think we will might eventually want a green/gray/red lock when we have more information about the actual details per-request. Weak algorithms could be called out in such a way. But until we have that data, a gray lock or nothing seems the right thing to do.
Comment on attachment 325863 [details] [PATCH] Proposed Fix View in context: https://bugs.webkit.org/attachment.cgi?id=325863&action=review r=me > Source/WebInspectorUI/UserInterface/Views/NetworkTableContentView.js:412 > + console.assert(!cell.firstChild, "We expect the cell to be empty.", cell, cell.firstChild); I'm not sure of the usefulness of this assertion. I understand that it will help catch edge cases, but it also seems to include quite a lot of detail. I personally think that just the check and message is enough, but it's your call.
The goal of the assertion is for the future. If we ever make Table.js reissue cells then this code could be improved. There is also only 1 column that does an in place update (waterfall) and it lacking the assertion helps make that known.
Comment on attachment 325863 [details] [PATCH] Proposed Fix Clearing flags on attachment: 325863 Committed r224391: <https://trac.webkit.org/changeset/224391>
All reviewed patches have been landed. Closing bug.