Closed Bug 769052 Opened 12 years ago Closed 4 years ago

SecReview: make tab strip async

Categories

(mozilla.org :: Security Assurance: Review Request, task)

task
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: curtisk, Assigned: mgoodwin)

References

Details

(Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy][Fx])

SecReview tracking bug
Actions regarding the review of the dependent bug should be tracked here.
My concern is the same as Gavin's in bug 743069 comment 1: the tab strip, URL bar, and content becoming out of sync for long enough to pose a spoofing risk.
Assignee: jruderman → nobody
sec-review? canceled on parent bug, do we need to keep this bug?
Assigning back to Jesse to either close this bug as we don't need it or do the review.
Assignee: nobody → jruderman
Status: NEW → ASSIGNED
I have no idea how to audit for that kind of problem.  It could involve complex interactions between tab strip code (e.g. bug 743069, bug 790567) and code elsewhere.  Not to mention the possibility of web pages breaking chrome JS (bug 611123, bug 732665) or content painting (bug 334359).
Assignee: jruderman → nobody
Assignee: nobody → mgoodwin
(In reply to Curtis Koenig [:curtisk] from comment #2)
> sec-review? canceled on parent bug, do we need to keep this bug?

I thought we didn't necessarily need the sec-review? on the parent bug if we had an explicit "review request" bug to cover it (to avoid double-counting requests).
Assignee: mgoodwin → nobody
Assignee: nobody → mgoodwin
No one is working on this; changing to unconfirmed until things start up again.
Status: ASSIGNED → UNCONFIRMED
Ever confirmed: false
Whiteboard: [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy] → [pending secreview][start mm/dd/yyyy][target mm/dd/yyyy][Fx]
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.