Closed Bug 508136 Opened 16 years ago Closed 11 years ago

ireflow can lead to Firefox never painting a new page

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jruderman, Unassigned)

References

Details

(4 keywords)

Attachments

(1 file)

Attached file testcase
1. Set the following environment variables: export GECKO_REFLOW_INTERRUPT_MODE=counter export GECKO_REFLOW_INTERRUPT_CHECKS_TO_SKIP=1 export GECKO_REFLOW_INTERRUPT_FREQUENCY=1 2. Run Firefox. 3. Load a web page. 4. Drag the testcase (as a local file) into a Firefox window. Result: old web page is still shown (zombie-like), but keypresses go to the testcase. Possible spoofing risk? The testcase is related to the one in bug 478527.
Flags: blocking1.9.2?
Flags: blocking1.9.2? → wanted1.9.2+
Would a web page be able to trigger this (with a different testcase) with the normal ireflow settings?
> Would a web page be able to trigger this (with a different testcase) with the > normal ireflow settings? With the new setup, almost certainly not. We set a timer to prevent OS event starvation, which should make sure that things get painted before we try reflowing again.
And in particular, I think that this bug should be either invalid or wontfix, depending on how we want to think about it...
Group: core-security
There's nothing to fix here afaict.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: