Closed Bug 409376 Opened 17 years ago Closed 17 years ago

getScreenCTM testcase fails on reload

Categories

(Core :: SVG, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: longsonr, Assigned: longsonr)

References

()

Details

(Keywords: regression, testcase)

Attachments

(1 file, 1 obsolete file)

Unlike bug 314214 the testcase in the URL does not have percentage types.

If you click shift reload then everything is fine. You get a Reflow which initialises the viewport size and then the onload which works.

When simply clicking on refresh things happen in the opposite order, you get the onload which fails as the viewport size is uninitialised (zero actually) and then the Reflow which initialises the viewport size too late.

This works in Firefox 2, but then that doesn't do reflow in the same way.
Does the result of getScreenCTM depend on layout?  If so, shouldn't it be flushing layout?
Flags: blocking1.9?
Attached patch patch (obsolete) — Splinter Review
Spot on Boris. I am all right using the ownerDoc rather than the currentDoc for the flush aren't I.
Assignee: nobody → longsonr
Status: NEW → ASSIGNED
Attachment #294277 - Flags: superreview?(bzbarsky)
Attachment #294277 - Flags: review?(bzbarsky)
Comment on attachment 294277 [details] [diff] [review]
patch

No, you really want to use the current doc, not the owner doc.  Furthermore, the flush can run arbitrary script, so you shouldn't really assume that things like the owner doc stay the same across the flush...
Attachment #294277 - Flags: superreview?(bzbarsky)
Attachment #294277 - Flags: superreview-
Attachment #294277 - Flags: review?(bzbarsky)
Attachment #294277 - Flags: review-
Attached patch currentDocSplinter Review
Attachment #294277 - Attachment is obsolete: true
Attachment #294288 - Flags: superreview?(bzbarsky)
Attachment #294288 - Flags: review?(bzbarsky)
Comment on attachment 294288 [details] [diff] [review]
currentDoc

Looks great.

This method isn't called from layout code, right?
Attachment #294288 - Flags: superreview?(bzbarsky)
Attachment #294288 - Flags: superreview+
Attachment #294288 - Flags: review?(bzbarsky)
Attachment #294288 - Flags: review+
The methods are part of the SVG DOM and called from javascript.
Attachment #294288 - Flags: approval1.9?
In case that wasn't a clear enough answer. No these methods are not called from layout code.
Comment on attachment 294288 [details] [diff] [review]
currentDoc

a=beltzner for 1.9
Attachment #294288 - Flags: approval1.9? → approval1.9+
checked in
Blocks: 314214
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b3pre) Gecko/2008010211 Minefield/3.0b3pre.
Flags: in-litmus?
https://litmus.mozilla.org/show_test.cgi?id=5068 has been added to the Litmus test suite.
Status: RESOLVED → VERIFIED
Flags: in-litmus? → in-litmus+
I just noticed that when you load that URL you do get this error in the console - I just wanted to note it: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIDOMSVGLocatable.farthestViewportElement]"  nsresult: "0x80004001 (NS_ERROR_NOT_IMPLEMENTED)"  location: "JS frame :: http://www.w3.org/Graphics/SVG/Test/20061213/svggen/types-basicDOM-01-b.svg :: testSVGLocatable :: line 33"  data: no].
Neither GetFarthestViewport nor GetNearestViewportElement are implemented (both are use on that page). I don't think there is a bug for that, so feel free to raise one if you wish.
raised bug 410811 for comment 12.
Flags: blocking1.9?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: