Closed
Bug 893424
Opened 13 years ago
Closed 13 years ago
Fix XULBrowserWindow's broken _hostChanged logic
Categories
(Firefox :: Security, defect)
Firefox
Security
Tracking
()
RESOLVED
FIXED
Firefox 25
People
(Reporter: dao, Assigned: dao)
References
Details
Attachments
(1 file)
|
4.62 KB,
patch
|
jaws
:
review+
|
Details | Diff | Splinter Review |
See bug 889428 comment 5.
| Assignee | ||
Comment 1•13 years ago
|
||
The only potential issue I can see with this is that checking gBrowser.currentURI in every onSecurityChange call surely is more expensive than checking this._hostChanged was, but probably not to an extent that we need to worry about it. As long as talos doesn't complain...
Updated•13 years ago
|
Attachment #775194 -
Flags: review?(jaws) → review+
| Assignee | ||
Comment 2•13 years ago
|
||
Comment 3•13 years ago
|
||
(In reply to Jared Wein [:jaws] from bug 889428 comment #5)
> In the case where this is failing, onSecurityChange is being called before
> onLocationChange, but there is an implicit ordering dependency between these
> functions since onLocationChange resets this._hostChanged and
> onSecurityChange checks this value.
Seems like maybe we should have a PSM bug on file to sort out whether this should be happening, given that these notifications exist solely to address UI needs this seems unexpected.
Comment 4•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 25
You need to log in
before you can comment on or make changes to this bug.
Description
•