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)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: jruderman, Unassigned)
References
Details
(4 keywords)
Attachments
(1 file)
|
528 bytes,
text/html
|
Details |
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+
| Reporter | ||
Comment 1•16 years ago
|
||
Would a web page be able to trigger this (with a different testcase) with the normal ireflow settings?
Comment 2•16 years ago
|
||
> 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.
Comment 3•16 years ago
|
||
And in particular, I think that this bug should be either invalid or wontfix, depending on how we want to think about it...
| Reporter | ||
Updated•16 years ago
|
Group: core-security
| Reporter | ||
Updated•12 years ago
|
Comment 4•11 years ago
|
||
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.
Description
•