165557 - BRANCH: views losing proper coordinates

Status: RESOLVED WORKSFORME

(Core :: Web Painting, defect)

Description

[Joe Francis]

using build Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1)
Gecko/20020823 Netscape/7.0

1) new browser window
2) go to url: http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
3) scroll main page so that mini ports view is at top of page
4) reload page (NOT shift reload)
5) reload again

bad things: the mini ports view draws in wrong place.  If it doesn't happen on
the second reload try a few more.  Some reloads it happens, some not, but it
seems to always happen on the 2nd for me.

Comment 1

[Joe Francis]

This bug is on branch.  :-(

Comment 2

[Simon Fraser [no longer active]]

Is this the infamous 'gray boxes' form control bug?

Comment 3

[Joe Francis]

also on todays trunk: Mozilla 1.1b

Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1b) Gecko/20020828

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Someone want to buy me a Mac? :-)

sfraser, I'll need your help. At least a screenshot...

Comment 5

[Simon Fraser [no longer active]]

Related to bug 164625?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We're about to find out, since I'm checking in the fix to 164625 right now :-)

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Fix checked in for 164625 ... please retest this on the Mac

Comment 8

[Joe Francis]

I pulled the 8-30 trunk bits and i still see the problem.  164625 work does NOT 
fix this.

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can someone give me a screenshot, at least?

I don't know if I'll be able to fix this without a Mac.

Comment 10

[Joe Francis]

Attachment: BRANCH screenshot (gif)

This same bug is also on the trunk.

Comment 11

[Joe Francis]

btw, though there are multiple tabs in the screenshot example, that is not
neccessary to repro the bug.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Looks like the view or widget may be incorrectly positioned. Does it always
appear at the same position when it is incorrect? Does it depend on anything
obvious, like where the scrollbar is during reload? Does it respond to events?

Can you narrow down the regression window?

Comment 13

[Joe Francis]

it's always offset as if the top of the content view were not scrolled.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Then it's probably a widget positioning bug.

pinkerton and sfraser are going to have to solve ths one.

Comment 15

[Simon Fraser [no longer active]]

Is this different from bug 137982?

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I can't do much with this. Reassigning to sfraser.

Comment 17

[Simon Fraser [no longer active]]

Do we care about this on the branch?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Is this on the trunk, or not?

Comment 19

[Andreas Kunz]

Joe, anybody:
this is only on the 1.0 branch, as filed?
This question was asked already more than a year ago. If it goes unanswered
again I'll assume it was correctly filed and is not a problem on the trunk
(someone would have mentioned it anyway).

Comment 20

[Wayne Mery (:wsmwk)]

WFM Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.5pre) Gecko/20091019 SeaMonkey/2.0.1pre