If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
RESOLVED WORKSFORME
7 years ago
6 years ago

People

(Reporter: Bruno Pagani, Unassigned)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [see comment 10], URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Updated

7 years ago
Version: unspecified → Trunk

Comment 1

7 years ago
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!

Updated

7 years ago
Keywords: regression, regressionwindow-wanted
(Reporter)

Comment 2

7 years ago
Created attachment 517030 [details]
Working under Chromium
(Reporter)

Comment 3

7 years ago
Created attachment 517032 [details]
Not working under Firefox

Comment 4

7 years ago
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
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins

Comment 5

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

Comment 6

7 years ago
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
Component: Plug-ins → General
Product: Core → Firefox
(Reporter)

Comment 7

7 years ago
I forgot buildID : 20110303194838
(Reporter)

Comment 8

7 years ago
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.

Updated

7 years ago
Attachment #517030 - Attachment is obsolete: true

Updated

7 years ago
Attachment #517032 - Attachment is obsolete: true

Comment 9

7 years ago
Created attachment 517047 [details]
Broken vs not
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
Status: UNCONFIRMED → NEW
Component: General → Plug-ins
Ever confirmed: true
Keywords: regressionwindow-wanted
OS: All → Windows 7
Product: Firefox → Core
Summary: Flash objects don't display → dofus.com flash objects not displayed as of 2011-02-12 nightly
Noming for visibility/investigation since recentish regression, so may affect other as yet unreported sites.
blocking2.0: --- → ?

Updated

7 years ago
Whiteboard: [see comment 10]
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

7 years ago
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
Blocks: 632003
http://staticgz.ankama.com/dofus/www/javascript/functions.includes.js contains a |var top| at top level, which hides Window.prototype.top.
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.
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?
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
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.

Updated

7 years ago
Assignee: nobody → general
Component: Plug-ins → JavaScript Engine
OS: Windows 7 → All
QA Contact: plugins → general
Hardware: x86 → All

Comment 19

7 years ago
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).

Updated

7 years ago
blocking2.0: ? → ---

Comment 20

7 years ago
(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.
I did check that document.compatMode was backCompat.  So I was definitely in quirks mode...
(Reporter)

Comment 22

7 years ago
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

7 years ago
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.
Per comment 22 and comment 23.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.