137378 - Form boxes not appearing

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[ahackett]

In the latest Nightlies (2002041003-2002041203) the form boxes used by BabelFish
at Altavista haven't been drawn. However in the case of the text boxes you can
still /use/ them, the combo box doesn't work at all and neither does the Submit
button.

I've checked in both W2K and Win98 and the problem shows up in both OSes.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Are you using XBL form controls, by any chance?  This worksforme, linux build
2002-04-12-21

Comment 2

[Boris Zbarsky [:bzbarsky]]

reassign to right place for real

Comment 3

[Boris 'pi' Piwinger]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020412

I see the problem using Win98SE.

Sorry, no ideas what "XBL form controls" are.

pi

Comment 4

[Boris Zbarsky [:bzbarsky]]

Under Preferences > Debug, is "Use XBL form controls" checked?  marking pp for
now, since I'm not seeing this on Linux....

Comment 5

[Boris 'pi' Piwinger]

In my case it is not checked.

pi

Comment 6

[kurros (Wade Majors)]

I was seeing this earlier tonight as well at babelfish, and was happening at
half.com as well. In both cases some of the text was still visible, but the
controls themselves were not drawn. Refreshing/Clicking back&forward a few times
made Mozilla behave.

I suspect this is broader problem.

Comment 7

[Adrian Ulrich]

also saw this yesterday..

using SHIFT+RELOAD solved the problem..
cache?

Build 2002041321

Comment 8

[Boris 'pi' Piwinger]

I have now also seen it on Linux (Mozilla/5.0 (X11; U; Linux i686; en-US;
rv:0.9.9+) Gecko/20020412) on groups.yahoo.com.

-> OS=ALL
-> Summary adjusted

As Adrian suggested, forced reload brings back everything. But, of course, there
are pages which won't accept such a reload (like home banking pages which result
from a POST).

pi

Comment 9

[ahackett]

Boris, I've checked the XBL prefs and the box is not checked.

Forced reload doesn't appear to work on W2K, nothing (including hitting back,
forward) seems to get Moz to draw the boxes. Not sure about Win98, I'll check
that when I get the chance.

Comment 10

[rods (gone)]

-->

Comment 11

[kinmoz]

Looks like fall out from bug 135146 (eliminate BRS_ISINLINEINCRREFLOW in favor 
of reflow roots). We seem to be getting a reflow targeted at a frame below the 
scrollframe that has the REFLOW_ROOT bit set, while the page is loading.

I verified that ignoring the bit, causes things to show up again.

Cc'ing other layout folks.

Comment 12

[Chris Waterson]

(FWIW, I cannot reproduce this on Linux -- can anyone else? I'm updating my
win32 build now.)

Comment 13

[kinmoz]

Attachment: Screen Shot of problem on Win2k.

Here's what the page is loading like for me. Notice that you can see the
contents of the text field ("http://") but nothing else. You can actually place
your caret and edit the textarea and textfield as the reporter mentions, by
clicking where the widgets should be.

Comment 14

[Boris 'pi' Piwinger]

Attachment: Screenshot of problem on Linux

As I said in comment 8, it also happens on Linux.

pi

Comment 15

[Chris Waterson]

Okay, thanks for confirming that. I'm not able to reproduce this, but will try
to find someone who is.

Comment 16

[kinmoz]

I mentioned this to waterson over IRC yesterday, but should've added it here too
... when I saved and loaded the http://babelfish.altavista.com page locally on
my machine at home, I was unable to reproduce the problem ... so perhaps network
delay (over my 38kbps modem connection) aids in reproducing this bug. (I hate
those kinds of bugs.) :-)

Comment 17

[Chris Waterson]

Attachment: stab in the dark

After talking about this with kin, it seems like a likely candidate for the
problem is failure to keep the table frame's timeout reflow count up-to-date.

When a reflow command is added to the queue,
NotifyAncestorFramesOfReflowCommand walks from the target all the way to the
root: this will cause the table frame to increment its `reflows pending'
counter. But when the text frame reflow is dispatched, it never visits the
table frame, since the text frame itself is used as the reflow root!

The fix (hopefully) is to modify NotifyAncestorFramesOfReflowCommand so that it
terminates notification with any frames that are NS_FRAME_REFLOW_ROOTs.

Since I can't reproduce the bug, I'd appreciate it if the people who _can_
could try this patch...

Comment 18

[Chris Waterson]

cc'ing karnaze: does the above explanation make sense?

Comment 19

[karnaze (gone)]

Comment on attachment 79477 [details] [diff] [review]
stab in the dark

r=karnaze. I applied the patch and it fixed http://babelfish.altavista.com on
win2k.

Comment 20

[kinmoz]

Comment on attachment 79477 [details] [diff] [review]
stab in the dark

sr=[e-mail]

Comment 21

[karnaze (gone)]

Forgot to mention - Comment #17 explains the problem; the table reflow 
coalescing mechanism assummed that all reflows started at the root frame. The 
regression tests in table/interactive should probably be invoked in addition to 
the automated ones.

Comment 22

[Asa Dotzler [:asa]]

can't put RC1 out the door with this problem. 
a=asa (on behalf of drivers) for checkin to the 1.0 branch. Quickly. We're about
to spin up (hopefully) final RC1 builds.

Comment 23

[Chris Waterson]

Checked in on the branch. Waiting for green to land on the trunk.

Comment 24

[Chris Waterson]

Fix checked in on trunk.

Comment 25

[Asa Dotzler [:asa]]

adding branch resolution keyword.

Comment 26

[Chris Waterson]

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

Comment 27

[kinmoz]

Just confirming that this also fixed the problem for me too.

Comment 28

[Itamar]

Since "need help testing" - wanted to say that it fixed my problem with Bug 137539
which was marked a dup of this one.

Comment 29

[ahackett]

About time I checked on this. Works for me as well now, cheers guys.

Comment 30

[Boris 'pi' Piwinger]

WFM: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020419
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020418

pi

Comment 31

[Madhur Bhatia]

verified fixed on branch