258763 - {inc} Nested position: absolute divs and tables display incorrectly until reflow

Status: RESOLVED WORKSFORME

(Core :: Layout: Positioned, defect)

Description

[Shelley Storch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040817
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a3) Gecko/20040817

Had to accomodate the fact you did not support document.all yet, but we worked
around this missing item.  
Now we are fighting positioning.  Standard HTML table within table cell
positioning is not working.  The submenu position is generally left of the main
menu item even when we are relative or absolute on our positioning by stating
left or right.  In addition, we tried several other options as well.
Was wondering the estimated time that these two items were scheduled to be
fixed?  I see a couple similar problems, but I do not know if these are exactly
the same.  
Sorry if this is a duplicate, but I am in need of information for development
reasons.
Thanks,
Shelley Storch 

Reproducible: Always
Steps to Reproduce:
1. Login to web page
2. Try hanging menu in portal
3. Modules/PreAuth to next level of the menu

Actual Results:  
Orginally, no hanging menus would appear because we were using document.all and
in the JavaScript Console it stated that it Document.All has no properties.  
We changed the document.all feature with a very long IF statement.  Then when we
went down the menu Modules to PreAuth, the next menu was generally to the left
of the PreAuth Item making it difficult to select any of the sub menu items. 


Expected Results:  
The submenu should of been right of the PreAuth Menu

Comment 1

[Daniel Veditz [:dveditz]]

No evidence of a security exploit, clearing security flag.

(Is this a bug report or a request for help? unclear, but requests for help
would get better responses in user support newsgroups or irc.)

Comment 2

[Mats Palmgren (inactive)]

Please attach a reduced testcase for the positioning problem using this URL:
http://bugzilla.mozilla.org/attachment.cgi?bugid=258763&action=enter

Comment 3

[Shelley Storch]

Attachment: This is the source from our web page that is having the positioning problem

We are more than willing to give you a login to our site so that you can
compare the differences between IE and Mozilla/Netscape.
If you would like to pursue a login you may contact me via e-mail and I'll get
you the information needed.
Thanks,
Shelley Storch

Comment 4

[Jason Barnabe (np)]

Shelley, are the layout differences visible in the source you attached here? If
so, what are they (screenshots)? If not, can you e-mail me the login info and
I'll take a look.

Comment 5

[Jason Barnabe (np)]

Attachment: reduced testcase

Something to do with bug 201897 (via bug 228781)?

Comment 6

[Jason Barnabe (np)]

Attachment: Firefox rendering before reflow

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040904
Firefox/0.9.1+

Comment 7

[Jason Barnabe (np)]

Attachment: Firefox rendering after reflow

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a3) Gecko/20040904
Firefox/0.9.1+

Comment 8

[Jason Barnabe (np)]

Attachment: IE rendering

IE 6 SP2

Comment 9

[Jason Barnabe (np)]

Attachment: Opera rendering

Opera 7.54

Comment 10

[Bernd]

I see a completely different rendering with winxp 2004090507 seamonkey

Comment 11

[Jason Barnabe (np)]

Moving to R & A Pos.

Comment 12

[Jason Barnabe (np)]

"Reflow" may not have been the best word to use. To get the "after" rendering,
resize the window.

(In reply to comment #10)
> I see a completely different rendering with winxp 2004090507 seamonkey

What do you see? (attach screenshots)

Comment 13

[Shelley Storch]

Jason,
I apologize for not attaching the screenshots.  This was the first time I have 
ever reported a bug to Mozilla.  With other companies I have dealt with like 
Hyland Software, the makers of OnBase, I dealt directly with the 
developer/technical support so this process is entirely different. 
I was not sure what to expect.  Hopefully, this will shed some light as to why 
I sent you the screenshots.  
I'll try to adhere to your reporting policy a little better.

Comment 14

[Jason Barnabe (np)]

(In reply to comment #13)
> I apologize for not attaching the screenshots.

Just to clarify: I wasn't asking you for screenshots in my latest comment, I was
asking Bernd for screenshots of what he sees.

Yes, ideally you should've attached screenshots or the files at first, but you
gave them to me on request. So all's well.

Comment 15

[Shelley Storch]

Attachment: Mozilla Picture

Attaching the original screenshot sent to Jason.

Comment 16

[Shelley Storch]

Attachment: IE Picture

The second screnshot showing the IE Alignment sent to Jason.

Comment 17

[Mats Palmgren (inactive)]

The testcase worksforme, Mozilla 1.8a5 and 2004-11-25-06 trunk on Linux.

Shelley, can you try Mozilla 1.8a5 on your site please.
http://www.mozilla.org/releases/

Comment 18

[Shelley Storch]

(In reply to comment #17)
> The testcase worksforme, Mozilla 1.8a5 and 2004-11-25-06 trunk on Linux.
> Shelley, can you try Mozilla 1.8a5 on your site please.
> http://www.mozilla.org/releases/

Downloaded the Windows version of 1.8a5, requesting clarification of whether 
change was incorporated to the Windows release prior to answering.  Please 
specify.  Thanks.

Comment 19

[Jason Barnabe (np)]

Shelley, I am using 1.8a5 for Windows (specifically, the Nov 25 build), and I no
longer see the bug that was exhibited in the testcase labelled "reduced
testcase". So yes, what we think was the problem is now fixed in the latest
builds. But it could be that there is another bug (with your code or with
Mozilla's) that is affecting your site, so we need either confirmation that it's
fixed or access to the site to keep trying to solve the problem.

Comment 20

[Shelley Storch]

(In reply to comment #19)
> Shelley, I am using 1.8a5 for Windows (specifically, the Nov 25 build)

Thanks for the clarification.
I have access granted to our test server please use this address:
https://www.accessta.com/CustomerTest/default.aspx
username: mozilla
password: welcome

In the new version of Mozilla the 1.8a5 we were seeing the second table left 
justified so it would instantiate over the first table menu.  I will post a 
view so you can see.  
In the case of IE the second table is right justified to the length of the menu 
word.  I'll send a picture of the IE so you get the general idea.

Comment 21

[Shelley Storch]

Attachment: Mozilla 1.85a Billing Menu Picture

This corresponds to my new message I sent today.
Second picture on the way.
Thanks

Comment 22

[Shelley Storch]

Attachment: IE Billing Menu Picture (Right Justified Sample)

This corresponds to my message today.
Thanks

Comment 23

[Jason Barnabe (np)]

Attachment: new testcase

This looks like an IE bug.

Comment 24

[Mats Palmgren (inactive)]

Mozilla's rendering of the testcase in comment 23 is correct. See 
http://www.w3.org/TR/CSS21/visudet.html#static-position

In the future, please report new problems by filing new bug reports, we prefer
to only handle one issue per bug report.

The original problem is WORKSFORME.