Closed
Bug 638768
Opened 14 years ago
Closed 13 years ago
dofus.com flash objects not displayed as of 2011-02-12 nightly
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bruno.n.pagani, Unassigned)
References
()
Details
(Keywords: regression, Whiteboard: [see comment 10])
Attachments
(1 file, 2 obsolete files)
(deleted),
image/jpeg
|
Details |
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•14 years ago
|
Version: unspecified → Trunk
Comment 1•14 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•14 years ago
|
Keywords: regression,
regressionwindow-wanted
Reporter | ||
Comment 2•14 years ago
|
||
Reporter | ||
Comment 3•14 years ago
|
||
Comment 4•14 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•14 years ago
|
||
Also, what exact build of Firefox 4 are you using? (Please copy from about:support)
Reporter | ||
Comment 6•14 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•14 years ago
|
||
I forgot buildID : 20110303194838
Reporter | ||
Comment 8•14 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•14 years ago
|
Attachment #517030 -
Attachment is obsolete: true
Updated•14 years ago
|
Attachment #517032 -
Attachment is obsolete: true
Comment 9•14 years ago
|
||
Comment 10•14 years ago
|
||
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
Comment 11•14 years ago
|
||
Noming for visibility/investigation since recentish regression, so may affect other as yet unreported sites.
blocking2.0: --- → ?
Updated•14 years ago
|
Whiteboard: [see comment 10]
Comment 12•14 years ago
|
||
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•14 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
Comment 14•14 years ago
|
||
http://staticgz.ankama.com/dofus/www/javascript/functions.includes.js contains a |var top| at top level, which hides Window.prototype.top.
Comment 15•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
Assignee: nobody → general
Component: Plug-ins → JavaScript Engine
OS: Windows 7 → All
QA Contact: plugins → general
Hardware: x86 → All
Comment 19•14 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•14 years ago
|
blocking2.0: ? → ---
Comment 20•14 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.
Comment 21•14 years ago
|
||
I did check that document.compatMode was backCompat. So I was definitely in quirks mode...
Reporter | ||
Comment 22•14 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•14 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.
Comment 24•13 years ago
|
||
Per comment 22 and comment 23.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•