Open Bug 1047111 Opened 10 years ago Updated 2 years ago

browser.blockedPopups.reported might not have the correct value

Categories

(Toolkit :: General, defect)

defect

Tracking

()

Tracking Status
firefox32 --- unaffected
firefox33 - wontfix

People

(Reporter: neil, Unassigned)

References

(Depends on 1 open bug)

Details

The old browser.pageReport used to recycle the array object. This meant that browser could set browser.pageReport.reported to true when it handled a popup while toolkit would reset browser.pageReport.reported to false when it processed a new popup, but not if there was an update for some other reason.

However the new browser.blockedPopups is a new array object every time. This means that browser.blockedPopups.reported might incorrectly be unset.
Blocks: 933462
No longer blocks: 934462
What are the practical effects of this? I have a hard time even following this code. Why does updateBlockedPopups need to be called on pageshow?
I see. I guess this could cause the page-report-button panel to disappear prematurely.

However, I'm not sure why we need to call updateBlockedPopups from pageshow or pagehide. I just copied what the old code did. I can see that you might want to filter out popups if an iframe navigates or something. But we already have a pagehide handler that clears blockedPopups, so that seems to defeat the purpose of the whole thing.
Assignee: nobody → wmccloskey
[Tracking Requested - why for this release]:
Tracking because it could be boring for some users but we probably won't block the release for this.

Updating the 31 tracking flags. Since 32 is unaffected, I guess it is the same for 31
Bill/Neil, I don't think this is serious enough to track this for upcoming releases. If you think otherwise, can you let me know?

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: bill.mccloskey → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.