638768 - dofus.com flash objects not displayed as of 2011-02-12 nightly

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Bruno Pagani]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 Gecko/20100101 Firefox/4.0

Previously, there was a problem with some flash objects in this page (and in others too), those objects were painting with a strange black background. This bug is now solved, I remember there was a bug report in Bugzilla for that.

For most websites, there are no more problems with that, but on some like the one linked, flash objected that were concerned don't display anymore.

Reproducible: Always

Steps to Reproduce:
1. Go to a website like http://www.wakfu.com/en/mmorpg
Actual Results:  
The flash banner in the middle left isn't displaying.

Expected Results:  
Should be displayed

On this (http://www.dofus.com/en/mmorpg-game/objects/2-items/1-amulet) page, in each white square, there is normally a picture in flash.

That is the same problem.

I think that this is linked with the fix of the black background problem, as it wasn't existing before and appears immediatly after the build including the fix.

Comment 1

[Ed Morley [:emorley]]

For http://www.wakfu.com/en/mmorpg I see no difference between Chrome dev 11 latest and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122446

Can you post working vs not screenshots so its easier to tell if what I'm seeing is correct or not - thanks!

Comment 2

[Bruno Pagani]

Attachment: Working under Chromium

Comment 3

[Bruno Pagani]

Attachment: Not working under Firefox

Comment 4

[Ed Morley [:emorley]]

In which case, Firefox works fine for me using the version in comment 1.

Could you see if the issue occurs with a new, empty profile:
http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_make-a-new-profile

Comment 5

[Ed Morley [:emorley]]

Also, what exact build of Firefox 4 are you using? (Please copy from about:support)

Comment 6

[Bruno Pagani]

I can't reproduce on that page with the last trunk and a clean profile, but still present on the other one.

I'm using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0

Comment 7

[Bruno Pagani]

I forgot buildID : 20110303194838

Comment 8

[Bruno Pagani]

Ok you can forget http://www.wakfu.com/en/mmorpg page, I found the problem, which was user specific.

But the other one still remains.

Comment 9

[Ed Morley [:emorley]]

Attachment: Broken vs not

Comment 10

[Ed Morley [:emorley]]

Thanks for the update.

Morphing bug so it's just about the dofus.com URL.

New STR (replaces comment 0)...
1) Visit: http://www.dofus.com/en/mmorpg-game/objects/2-items/1-amulet
2) Observe square to the left of the description box

Expected:
- Image of item (see attached screenshot)

Expected:
- Blank flash object (see attached screenshot)
- Note the flash context menu still appears when right clicking, so the flash object is there, just not visible.

Confirmed with Flash v10.2.152.26 and Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303122446


Using m-c...
Last good nightly: 2011-02-11 
First bad nightly: 2011-02-12
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=1ed3464aaa92&tochange=9698ac3f1c61


Using tm...
Last good nightly: 2011-02-11 
First bad nightly: 2011-02-12
Pushlog: http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=8c7a2550e761&tochange=bce779f4d16b

Comment 11

[Ed Morley [:emorley]]

Noming for visibility/investigation since recentish regression, so may affect other as yet unreported sites.

Comment 12

[Ed Morley [:emorley]]

Tested with hardware acceleration disabled.

Approx 10+ errors in error console all the same as:

Error: top is undefined
Source File: javascript:top.location+"__flashplugin_unique__"
Line: 1

Plus a load of warnings.

Comment 13

[Alice0775 White]

Pushlog:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=94e3767a268d&tochange=38536e8a2194
Regressed by:
38536e8a2194	Igor Bukanov — bug 632003 - var declarations should ignore prototype properties, r=jwalden

Comment 14

[Jeff Walden [:Waldo]]

http://staticgz.ankama.com/dofus/www/javascript/functions.includes.js contains a |var top| at top level, which hides Window.prototype.top.

Comment 15

[Jeff Walden [:Waldo]]

I don't see how that |var top| serves any obvious purpose in the script, for what it's worth.  The script doesn't refer to |top|, as a variable or as the topmost frame, in any way.

Comment 16

[Boris Zbarsky [:bzbarsky]]

So... the way Flash does this javascript: stuff to try to get the location is just broken.  We really really need to just give them a way to do this via npapi.

I see no way to make this work without either a change in Flash, a change in this site, or backing out bug 632003...

By the way, note that if the page had done:

  var top = 5;

that would have broken this flash stuff even in 3.6, since "top" is a replaceable property, right?

Comment 17

[Brendan Eich [:brendan]]

javascript:alert(window.hasOwnProperty('top')) shows true in Safari, Chrome, and Opera. I can't test IE but I bet it's true there too. The Gecko DOM has put 'top' on the prototype chain for a long while (I forget if the pre-xpcdom did it that way; IIRC Netscape 2-4 had 'top' as an own property, along with 'parent', 'self', and 'window').

In Chrome and Safari,

javascript:d=Object.getOwnPropertyDescriptor(window,'top');alert(d.configurable)

shows false, and writable shows true. But in Chrome and Opera,

javascript:var top=42; alert(top)

shows "[object DOMWindow]" (Chrome) or "[object Window]" (Opera), not "42". Only Safari honors writable:true and shows "42".

Backing out has to be an option. Another (not exclusive; longer term, vs. short term back-out) approach is to do what Safari does and provide 'top' as a writable data property.

/be

Comment 18

[Boris Zbarsky [:bzbarsky]]

What Safari does is not compatible with what HTML5 and WebIDL are currently specifying.

In IE9, window.hasOwnProperty('top') tests false (in both standards and quirks mode).  Object.getPrototypeOf(window).hasOwnProperty('top') tests true.

Unfortunately, installing the IE9 RC blew away my IE8 install, so I can't tell you what IE8 does.  But I'm pretty sure that |var top| shadows there as well.

I think the long-term plan here should be to get Flash to stop running script in untrusted contexts where it can easily be tricked to retrieve things like this.  We should expose more information via NPAPI as needed instead.

Comment 19

[Andreas Gal :gal]

Not blocking on this. If the RC shows that this breaks a ton of stuff, we will react. Otherwise we will fix when we get the chance (.x or FF5).

Comment 20

[Allen Wirfs-Brock]

(In reply to comment #18)

> Unfortunately, installing the IE9 RC blew away my IE8 install, so I can't tell
> you what IE8 does.  But I'm pretty sure that |var top| shadows there as well.
> 
For the record, here's what I observed when I experimented with IE8:

The global object is a host object in IE8 and it doesn't inherit from Object.prototype.  you can't do:
   window.hasOwnProperty('top')
but you can do:
   ({}).hasOwnProperty.call(window,'top')
and it returns true.
   var top=5; widow.top+top 
returns 10, the var initialier is over-writing, not shadowing the window property.

Personally, I'm surprised by the what was reported in comment 18 about IE9 quirks mode as that seems like a breaking change (for that mode) of the sort that IE doesn't want to have.  Perhaps it's a bug or perhaps you really didn't get into quirks mode.

Comment 21

[Boris Zbarsky [:bzbarsky]]

I did check that document.compatMode was backCompat.  So I was definitely in quirks mode...

Comment 22

[Bruno Pagani]

Seems to be fixed now (Mozilla/5.0 (X11; Linux i686; rv:6.0a1) Gecko/20110413 Firefox/6.0a1 20110413035228).

If someone can confirm, I think we can change status to Resolved.

Comment 23

[Alice0775 White]

Confirmed on http://hg.mozilla.org/releases/mozilla-2.0/rev/6be9e31d01b4
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0 ID:20110318052756

maybe fixed by site because it works on nightly:
http://hg.mozilla.org/mozilla-central/rev/9698ac3f1c61
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12pre) Gecko/20110212 Firefox/4.0b12pre ID:20110212030346
and 4.0 release vearsion as above.

Comment 24

[Jeff Walden [:Waldo]]

Per comment 22 and comment 23.