Closed Bug 508136 Opened 11 years ago Closed 6 years ago

ireflow can lead to Firefox never painting a new page

Categories

(Core :: Layout, defect)

x86
macOS
defect
Not set

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: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.