Open Bug 1358975 Opened 7 years ago Updated 2 years ago

[e10s] The option checked for <select> disappears when opened for the first time

Categories

(Core :: Layout: Form Controls, defect, P3)

55 Branch
x86_64
Windows 7
defect

Tracking

()

Tracking Status
firefox53 --- unaffected
firefox54 --- unaffected
firefox55 --- fix-optional
firefox56 --- fix-optional
firefox57 --- ?

People

(Reporter: over68, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(1 file)

Steps to reproduce:

1. Go to https://onedrive.live.com/download?cid=F96BA52A2AF70D03&resid=F96BA52A2AF70D03%211362&authkey=ACzTTnL6f5-eFoI.
2. Open the <select> element.


Actual results:

The option checked for <select> disappears and shows when opened for the first time.
Flags: needinfo?(jaws)
This is happening because we recreate all of the DOM nodes on transitionend during update. Instead of just deleting everything, we could compare what was previously used to create the menu with what was determined via the transitionend, and if it's not any different we can bail out of the update without replacing all of the nodes.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jaws)
I have attached a test that will fail if the nodes are removed, but I don't have time right now to implement the code that only updates what has changed.
Does it still reproduce? Seems OK here.
Flags: needinfo?(over68)
I can reproduce this bug with the latest nightly build.
Flags: needinfo?(over68)
Priority: -- → P2
Does this still happen for 57?
Blocks: e10s-select-styling
No longer blocks: e10s-select
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: