353460 - SVG image has no horizontal scrollbar

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Ria Klaassen (not reading all bugmail)]

I saw this while testing Bug 353450; the image in attachment 239300 [details] of Bug 353450 has no horizontal scrollbar in trunk. Branch displays the scrollbar.

Regression between 1.9a1_2006031504 and 1.9a1_2006031521:
http://bonsai.mozilla.org/cvsquery.cgi?module=PhoenixTinderbox&date=explicit&mindate=2006-03-15+03%3A00&maxdate=2006-03-15+22%3A00

Caused by Bug 192767?

Comment 1

[Robert Longson [:longsonr]]

Attachment: patch

There are so many testcases in bug 192767 I found it rather hard to tell if I've broken any of them.

Comment 2

[Robert Longson [:longsonr]]

Attachment: testcase

Comment 3

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

If the comment says it doesn't matter, why does it matter?  In what cases is the comment wrong?  SVG only, or others?  Have you tested those others?

Comment 4

[Peter van der Woude [:Peter6]]

Attachment: simplified testcase

2000x2000 px svg, the horizontal scrollbar fails

Comment 5

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

Comment on attachment 239542 [details] [diff] [review]
patch

marking review- pending answer to question

Comment 6

[Robert Longson [:longsonr]]

Sorry for the delay responding to the question. I have looked into this further and since image frames work OK, perhaps this would be fixed by implementing bug 288276 comment 22 rather than the change I originally proposed. I'm going to look at doing things that way when I have time and see if scrolling then comes out in the wash.

Comment 10

[Jonathan Watt [:jwatt]]

Attachment: patch

Comment 11

[Jonathan Watt [:jwatt]]

I'm not sure about the FinishAndStoreOverflow calls. It's unclear to me from that method's documenting comment under what circumstances you should or shouldn't call it. The scrolling is fixed with or without it, but it seems like a good idea to store the size since reflowing to get the size would be horribly expensive. Also there's unlikely to be that many nsSVGOuterSVGFrame objects per document.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 278970 [details] [diff] [review]
patch

In your case you never have overflow, so it doesn't matter much whether you cann FinishAndStoreOverflow... but it's the Right Thing To Do.

r=bzbarsky, but get roc to sr, ok?

Comment 13

[Jonathan Watt [:jwatt]]

Comment on attachment 278970 [details] [diff] [review]
patch

Sure thing. Thanks Boris.

Comment 14

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

Comment on attachment 278970 [details] [diff] [review]
patch

this is OK. However, I actually think nsSVGOuterSVGFrame should calculate its overflow area as the bounding box of its descendants. Another time.

Comment 15

[Jonathan Watt [:jwatt]]

Checked in. I added a comment to that effect.

Comment 16

[Robert Longson [:longsonr]]

The comment should use "in principle" rather than "in principal"

Comment 17

[Jonathan Watt [:jwatt]]

Oops.