ireflow issue with <select>

NEW
Unassigned

Status

()

Core
Layout
--
minor
9 years ago
9 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {testcase})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
Created attachment 362439 [details]
testcase (based on layout/generic/crashtests/391053-1.xhtml)

Steps to reproduce:
1. Apply the ireflow patch (bug 67752 comment 56).
2. 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
3. Load the testcase
4. Click the <select>

Result: clicking changes the size.

Based on CPU usage, I'm guessing ireflow never finishes.  Is that expected given the testcase and settings?

refdyn complained about layout/generic/crashtests/391053-1.xhtml, but this might not be the same issue that made refdyn unhappy.
Yeah.  Given the testcase and settings, I'd expect us to never complete a reflow here.  This shouldn't affect refdyn, since trying to snapshot will flush out a non-interruptible reflow.

I could disable interruption inside a listbox, but I think this shouldn't be an issue when using the user-event approach....
Yeah, I think we should at least give it a go with user events and see if starvation is a problem in practice.
You need to log in before you can comment on or make changes to this bug.