27233 - JS fill-in is very slow

Status: VERIFIED DUPLICATE of bug 53165

(Core :: DOM: Core & HTML, defect, P1)

Description

[Sarah Dwyer]

The javascript fill-in on the bug reporting form is very slow. I would guess
that if you use any form and dynamically repopulate a form with JS it would be
very slow.

Comment 1

[Steven de Hoog]

*** Bug 27229 has been marked as a duplicate of this bug. ***

Comment 2

[daver]

passing on to Don.  Should someone in your group own this?

Comment 3

[lchiang]

correcting the product to Browser

Comment 4

[gerardok]

Prashant, please could you look at this? Thanks

Comment 5

[verah (gone)]

Reassigning as per Don

Comment 6

[rods (gone)]

setting to M17

Comment 7

[rods (gone)]

This is a known issue with to many reflows being scheduled when selects are 
filled in via script

Comment 8

[rods (gone)]

*** Bug 32920 has been marked as a duplicate of this bug. ***

Comment 9

[rods (gone)]

Attachment: simple textcase

Comment 10

[rods (gone)]

*** Bug 45017 has been marked as a duplicate of this bug. ***

Comment 11

[rods (gone)]

*** Bug 45075 has been marked as a duplicate of this bug. ***

Comment 12

[Akkana Peck]

Adding nsbeta3 keyword.  This makes the bugzilla query page really ugly: try
loading the query page, then change Product to Mail, and watch for 3-5 seconds
(Linux optimized build) as the combo boxes repaint over and over and over again.

Comment 13

[rods (gone)]

Nisheeth's comment from an e-mail:

I see two possible solutions here:

1) Send it to Moz Cafe for lunch so that it comes back really fast.
2) We could use the BeginReflowBatching/EndReflowBatching API on the 
pres shell to batch reflows during the EvaluateScript() call in the 
content sink.  This should help as long as the script does not 
repeatedly call property getter methods that flush pending reflow 
commands because they require the frame model to be up to date.

Comment 14

[Kevin McCluskey (gone)]

Marking nsbeta3-

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration. 
  

Comment 15

[Jeffrey Baker]

*** Bug 52791 has been marked as a duplicate of this bug. ***

Comment 16

[Hixie (not reading bugmail)]

Triaging QA. Jan, is this yours?

Comment 17

[rods (gone)]

*** Bug 53942 has been marked as a duplicate of this bug. ***

Comment 18

[Asa Dotzler [:asa]]

*** Bug 53960 has been marked as a duplicate of this bug. ***

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is this a duplicate of bug 30091?

Comment 20

[rods (gone)]

It certainly could be effecting it, but I would be suprised if it is completely 
responsible for it. I'll set it as a dependency so I can test when Bug 30091 is 
fixed.

Comment 21

[Jesse Ruderman]

Adding bug 46298 as blocking this bug.

Comment 22

[John Unruh]

*** Bug 60684 has been marked as a duplicate of this bug. ***

Comment 23

[rods (gone)]

I will take another look at this, it may get faster with lazy dropdowns

Comment 24

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The problem here seems to be that we are causing lots of reflows by calls to
nsGenericHTMLElement::GetPrimaryFrame(), which calls
nsHTMLDocument::FlushPendingNotifications.  In the case of bugzilla query page
component switching, these calls are coming from
nsHTMLOptionElement::GetSelected().  In the case of loading test8 (although it
doesn't account for as much of the time there), they're coming from
nsHTMLTextAreaElement::HandleDOMEvent and nsHTMLSelectElement::HandleDOMEvent.

GetPrimaryFrame does take an extra argument (with a default value of PR_TRUE)
for whether to flush notifications, but that may or may not be the correct
solution...

Comment 25

[Phil Schwartau]

*** Bug 69979 has been marked as a duplicate of this bug. ***

Comment 26

[rods (gone)]

Going to take another look and see why we are flushing the pending events each time.

Comment 27

[Jan Carpenter]

QA Contact -> gerardok

Comment 28

[rods (gone)]

*** Bug 73396 has been marked as a duplicate of this bug. ***

Comment 29

[rods (gone)]

*** Bug 74060 has been marked as a duplicate of this bug. ***

Comment 30

[rods (gone)]

*** This bug has been marked as a duplicate of 53165 ***

Comment 31

[Chad Austin]

verified dup