96413 - Doubling of form elements on Bugzilla pages

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[James Green]

Build: today's tip pulled at 0900BST (0000PDT) using gcc2.95.4.

Steps to reproduce:
1. Click on any bug number to load the report
2. Whilst the report is loading from the network, as soon as the vertical
scrollbar appears, use it to scroll downwards past the form at the top.
3. Once page has loaded, scroll up

Expected results:
Should show the form at the top of the page once and correctly

Actual Results:
Two forms are displayed, almost identical, one on top of the other.
The first contains no pull down menu items
The second appears apparently correctly.

This was tested using a new profile.

Screenshot coming up.

Comment 1

[James Green]

Attachment: Screenshot showing problem

Comment 2

[Doron Rosenberg (IBM)]

-> layout, cc:rods as he owns HTML Form Controls, blocker for now

Comment 3

[James Green]

I should add, the first time I saw this this morning, I was trying to change a
bug'd target milestone, and noticed that all form control pull-downs has gone.
On this occassion, there was NO second copy of the form, and thus I was unable
to change any part of the bug expect additional comments. That may make this a
smoketest blocker. Can anyone else reproduce?

Comment 4

[Bernd]

I'v seen this too with 2001-08-22-03 Win98

Comment 5

[karnaze (gone)]

With some difficulty, I was finally able to reload bug 46268 (a fairly long one) 
and scroll down before it finished loading. When I scrolled back up, I did not 
see the problem on my Win2K debug build of 8/21/01 9am which also included my 
checkins from last night; I did this a few times. I think my build also included 
rods' changes to form controls.

Comment 6

[Bernd]

I screened the last night's checkins for 'scroll' and found a fix for bug 93830.

Comment 7

[karnaze (gone)]

Randall, can you take a look at this and see if your patch to bug 93830 caused 
it. 

Comment 8

[James Green]

OK just found another way. I loaded this bug, then hit shift+reload to force a
network refresh, and immedately found the 'blank' form on top of a good form
*without* needing to scroll at all.

Curiously, the textarea for Additional Comments in the 2nd (good) form, refused
to accept backspace or delete, so when I made a mistake, I had to hit reload
again and got a single form with *correct* form fields.

Comment 9

[James Green]

OK just went back to "Today's Bug List" and clicked on this report, was
immediately faced by the same two forms, first having no pull downs, the second
having backspace and delete disabled. Scrolling may be neccessary the first
time, I don't know.

Comment 10

[Bradley Baetz (:bbaetz)]

randell just checked the patch in, so if that patch is causing the problem, this
is gisburn's.

-> him

Can someone who has a current build try backing that patch out?

Comment 11

[James Green]

Definitely doesn't require scrolling. I hit 'Commit' on those last comments, and
was imediately faced with the next bug in the list with the problem of two
forms, first one being blank. I hadn't previously loaded that bug, so it's not a
cache thing.

Bernd sees on Win32, marking All/All. Are people seeing this as serious and
widespread enough to get the magic 'smoketest' keyword?

Comment 12

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

I somehow doubt that was the cause.  I've also seen this before today's build, I
think.  (Maybe yesterday's?)

Comment 13

[Roland Mainz]

I am not sure how my patch in bug 93830 should cause this... and I doubt it
causes this trouble because I had the patch three weeks in my tree and I never
observed such a problem (well, I am still using NS4.x for
BugZilla/Email/News...)...

I may only be a problem if |aPresContext->IsPaginated(&isPaginated))| returns a
wrong value... but I doubt that...

----

Setting target milestone 0.9.4 - blockers should always have a milestone...

Comment 14

[Bernd]

I backed out, the problem persists

Comment 15

[Roland Mainz]

bernd:
Does that mean I am not guilty ?

Comment 16

[Roland Mainz]

per comments in this bug:
Reassigning to bug to owner and QA contact of layout component...

Comment 17

[James Green]

This is hitting me on almost all bug pages I pull up, and I've noticed the
following:

1. In the 2nd form, apparently correct, you can't hit delete or backspace. Make
a mistake in the Additional Comments field, and you can't correct it.

2. Same form, the radio buttons at the bottom are all doubled up. So you get two
of "Accept bug", four "Resolve bug", etc.

Comment 18

[Scott Tran (Wildcard)]

Whats the ETA on this bug ? The backspace/delete problem along with the bug
rendering make bug triaging very difficult...

Comment 19

[Asa Dotzler [:asa]]

this has a much higher frequency on slow connections. This blocks all use of
Mozilla for work in Bugzilla. 

Comment 20

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

Could someone who can reproduce reliably try to narrow down between which two
builds this started?  I see it occasionally, but not often enough to
binary-search the builds.

Comment 21

[Andreas M. "Clarence" Schneider]

Cannot reproduce with 2001-08-20-08, Win NT (found in 2001-08-20-15-trunk),
but can reproduce with 2001-08-21-09, Win NT (found in 2001-08-21-11-trunk).
Note that forms changed to use proportional fonts between the two builds
(didn't find the bug # for that).

Comment 22

[Ashley Bischoff (blog at handcoding.com)]

Clarence: Proportional fonts in bug 96414.

Comment 23

[Andreas M. "Clarence" Schneider]

No, I meant bug 91602.

Comment 24

[Andreas M. "Clarence" Schneider]

Can anybody reproduce this after adding this pref:
user_pref("layout.forms.use_standard_or_quirks", true);
I can't, but my connection to bugzilla seems to be very fast ATM.

Comment 25

[Andreas M. "Clarence" Schneider]

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

Comment 26

[Markus Gerstel]

I'm sorry but this bug doesn't have anything to do with scrolling around, so
I'll change the Summary.

Additional : Annoying because you cannot change any bug in Bugzilla (The Bug #
gets doubled too : 9676996769) and reloading the page never changes anything.

Interesting: Every time I encounter this the top "mozilla.org" image is shown
somewhere inside the page (most of the time only parts of the image) then these
parts "move" up to the correct position. Screenshots are in Attachement 47142
and Attachement 47143

Interesting too: Selecting the doubled elements =) See Attachement 47141 (all
attachements filed on Bug 96769

Comment 27

[Markus Gerstel]

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

Comment 28

[Andreas M. "Clarence" Schneider]

Assigning to rods because his check-in for bug 91602 seems to have regressed this.
doctor__j found the same as I in bug 96769.

Comment 29

[Andreas M. "Clarence" Schneider]

(re-changing summary wasn't intentional)

Comment 30

[Ashley Bischoff (blog at handcoding.com)]

> and reloading the page never changes anything.

Markus: FWIW, I've found that "Super Reloading" (shift-Reload) always fixes the
problem for me (even though, as you mention, normal-reloading does nothing). 

Comment 31

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

Attachment: interesting debugging notes

Comment 32

[Scott Tran (Wildcard)]

Andreas, 
Adding user_pref("layout.forms.use_standard_or_quirks", true);
to my prefs.js fixed the problem for me, used to be able to reproduce 100% of
the time, now I cant reproduce at all

Comment 33

[xyzzy]

I am also seeing this behavior when switching windows while the page loads on
Win98.  Hoping this makes it easier to reproduce...

Comment 34

[rods (gone)]

I am not able to reproduce this bug with any of the techniques described so far.

I would certain slwly remove standard sizing on each control until it worked 
again.

Comment 35

[doctor__j]

Using 1024x768 screen resolution and just loading this page a few times
(Shift-reload sometimes) and the bug pops up for sure.  No need to do any
special move...

Comment 36

[rods (gone)]

Doc J, are you using a modem?

Comment 37

[rods (gone)]

I had to re-checkin a radio button fix that could possibly be responsible for 
this. 

The fix was to disable the auto-selection of the first item, which was going 
back into the content which could have been causing problems.

Comment 38

[Ryan Pertusio]

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

Comment 39

[rods (gone)]

Is this a dup of Bug 96142?

I can get 96142 to do it every time.

Comment 40

[rods (gone)]

Bug 96142 is NOT a dup of this, it has two DIVs

Comment 41

[kysmith0 (gone)]

I can't repro this with buildid 2001082708 following first set of repro steps 
in the bug report, downgrading to critical. 

Comment 42

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

I'm actually not able to reproduce today using steps that worked for me
yesterday (in viewer, with --trace-malloc malloc.log, in a build with
trace-malloc enabled).

Comment 43

[James Green]

My build this morning on Linux (pulled 0900BST) was able to reproduce this problem.

I have now pulled from the tree folllowing new checkins from rods. Pull time was
approximately fifteen minutes ago. I no longer able to reproduce this problem.
Suggest marking RESOLVED FIXED by latest code, unless anyone else can reproduce
with a similarly recent build.

Comment 44

[rods (gone)]

My guess is that it was the nsFormFrame.cpp check for the auto-select radio btn 
issue, as I had suggested before. marking WFM

Comment 45

[Chris Petersen]

Confirming WFM with the Sept 28th branch builds: Mac OS X (2001-09-28-04) and
Windows ME (2001-09-28-05).