Bug 11673 – REGRESSION(r14067): Dojo examples don't load in iframe

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: New Bugs

[Matt Lilek]

The examples at the provided url (click the "See it in Action" tab for the examples) don't load in the iframes on the example page, but loading them in a new tab/window loads them fine (http://dojotoolkit.org/dojo/demos/widget/Mail.html).  Appears to be a side effect of the loader refactoring.

[Joost de Valk (AlthA)]

Works for me... Reporter: please check in latest nightly, and reopen if it still doesn't work for you.

[Matt Lilek]

Reopening as this is still an issue.

Load the website, click "see it in action", click "Demo Applications" and finally "View Demo" under the Mail example.  Firefox loads it fine, WebKit doesn't.  I get a number of these errors printed to the console in my debug build of r18973:

ERROR: unimplemented propertyID: 46
(/Users/matt/Code/WebKit/WebCore/css/CSSComputedStyleDeclaration.cpp:1474 WTF::PassRefPtr<WebCore::CSSValue> WebCore::CSSComputedStyleDeclaration::getPropertyCSSValue(int, WebCore::EUpdateLayout) const)

[Stephanie Lewis]

In Radar<rdar://problem/4947072>

[Darin Adler]

As I suspected, implementing computed style for box-sizing got rid fo the log message but didn't make the Dojo examples work.

The actual problem does seem to be something related to frame loading.

[Maciej Stachowiak]

I'm not sure this has anything to do with loading. If you look at the frame source for the example frame, or inspect it in the web inspector, it looks like the elements are all there, and have proper style and layout metrics. But nothing seems to paint!

[Matt Lilek]

I was just looking at this last night.  The reason we're not painting is because they're setting the width of the example iframe's parent div to 0 in ToT.  I'm not sure if thats an intermediate step that happens on all browsers but is then changed and that isn't happening on ToT (spoofing as another browser doesn't do anything) or what as reducing the Dojo code is, erm, "fun"...

[Maciej Stachowiak]

Works in r13060.

[Matt Lilek]

Whatever caused this happened between r14055 and r14071.

[Maciej Stachowiak]

I definitively tracked this down to r14067. It seems like that patch should only have affected computed margin and padding; not clear why it results in a width of 0px.

[Maciej Stachowiak]

Created attachment 13337 [details]
start on a reduction

Here's a start on a reduction, all in one file. It's still huge. I think I may have also over-reduced this, ass adding back the iframe I took out does result in the frame showing up now, although the height of its containing div is still wrong.

[Maciej Stachowiak]

Indeed, my reduction still fails with the revision before the regression, so I think it is just an unrelated Safari/Firefox behavior difference.

[Maciej Stachowiak]

Revision that regressed this is http://trac.webkit.org/projects/webkit/changeset/14067

[Maciej Stachowiak]

I talked to Alex Russel of Dojo fame about this, and he pointed out that soon a new version of the Dojo site will be launching. The preview version does't show this bug with ToT WebKit, but ironically, it fails in a similar way with Safari 2.0.4.

[Matt Lilek]

Dojo updated their website and this bug doesn't show anymore.  Closing since we could never figure out exactly what caused it.