381746 - odd and changing border in frameset

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Peter van der Woude [:Peter6]]

Attachment: screenshot

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/20070522 Minefield/3.0a5pre ID:2007052219 [cairo] (last working build)

There appears a strange border in the left frame.

http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=1179885660&maxdate=1179892439

On the screenshot the top part is the correct display.
The bottom 3 occur after above regressionrange when (re)loading the page

Comment 1

[Peter van der Woude [:Peter6]]

If the frame is resized it reflows to the correct layout

Bug 365189 ?

Comment 2

[Martijn Wargers (dead)]

Attachment: testcase

Comment 3

[Martijn Wargers (dead)]

Attachment: reference rendering

Comment 4

[Martijn Wargers (dead)]

Attachment: testcase

ok, apparently the previous testcase only shows the bug when testing it locally.
I hope this one shows the bug online.

Comment 5

[Martijn Wargers (dead)]

Attachment: testcase

Sorry for all the wrong attachments. This should finally be a good testcase.

Comment 6

[Martijn Wargers (dead)]

Attachment: reference rendering

Comment 7

[Eli Friedman]

Switching to correct dependency.

Comment 8

[Eli Friedman]

Attachment: Patch

Basically, the view code seemed like it expected a call to ResetWidgetBounds, but never actually got one.  So this patch is mostly code reorganization to make everything work correct without it.  (The reason things were looking weird was that mViewToWidgetOffset wasn't getting initialized.)

Comment 9

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

Comment on attachment 265890 [details] [diff] [review]
Patch

+void nsView::CalcWidgetBounds(nsRect& aRect, nsWindowType aType)

This could just return the rect as the result.

Comment 10

[Eli Friedman]

Checked in (and BTW, there's no need to mark any patches by me with checkin-needed; if I really need it, I'll request it myself.)

Comment 12

[Stephen Moehle]

I think this fix caused bug 382111. At least, backing this out fixes it.

Comment 13

[Eli Friedman]

Marking fixed (I guess I forgot when I commented before.)

Comment 14

[(not currently active) Ted Mielczarek]

It looks like this may have caused a crash.  Looks like a null pointer deref.  See for example:
https://crash-reports.mozilla.com/reports/report/index/2ce2d7d1-0e5a-11dc-aba0-001a4bd43e5c

Comment 15

[Martijn Wargers (dead)]

Thanks Ted, this happens when trying to print a <select>.
I discovered this by the Talkback comments:
http://talkback-public.mozilla.org/search/start.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsView::CalcWidgetBounds&vendor=MozillaOrg&product=FirefoxTrunk&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid
(*hint hint*, talkback comments can be very useful, sometimes)
I filed bug 382471 for this.

Comment 16

[Mats Palmgren (inactive)]

Pushed the attached reftest:
http://hg.mozilla.org/mozilla-central/rev/4ada4073af8a

Comment 17

[Henri Sivonen (:hsivonen)]

http://mxr.mozilla.org/mozilla-central/source/layout/reftests/bugs/381746-1.html?force=1
fails with the HTML5 parser. Presumably because the test doesn't wait for the load events of the data: URLs. See
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/15dde937788406cd/07cd9ca6679c1475

Comment 18

[Henri Sivonen (:hsivonen)]

Attachment: Make the reftest wait for iframe onloads

Fix for the reftest.

Comment 19

[Mats Palmgren (inactive)]

Comment on attachment 431617 [details] [diff] [review]
Make the reftest wait for iframe onloads

Thanks, I'll try to remember that in the future. r=mats

Comment 20

[Henri Sivonen (:hsivonen)]

Thanks. Pushed:
http://hg.mozilla.org/mozilla-central/rev/8606d3764288