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.
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]:
status-firefox31: --- → wontfix
status-firefox32: --- → unaffected
status-firefox33: --- → affected
status-firefox34: --- → affected
tracking-firefox33: --- → ?
tracking-firefox34: --- → ?
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
status-firefox31: wontfix → unaffected
tracking-firefox33: ? → +
tracking-firefox34: ? → +
4 years ago
No longer blocks: 1054840
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?
status-firefox31: unaffected → ---
status-firefox33: affected → wontfix
status-firefox34: affected → ---
tracking-firefox33: + → -
tracking-firefox34: + → ---
You need to log in before you can comment on or make changes to this bug.