54448 - Flash-enabled site doesn't show up

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P1)

Description

[dbragg]

Visiting Peter Gabriel's Real World studios site (http://www.realworld.on.net)
takes me immediately to http://www.realworld.on.net/index/flash.html and the
main browser screen goes blank.  I don't know if this is a Seamonkey6 bug or a
Shockwave Flash bug.  I checked to make sure that npswf32.dll is in my plugins
folder for Netscape6.  That is the Shockwave flash plugin right?

In 4.7, if I click on the flash enabled link on the first page or I wait about
30 seconds, I'm taken to http://www.realworld.on.net/index/f_flash.html (note
the f_ before flash.html). I don't know why the f_ is not there in Seamonkey but
is there on 4.7.  Anyway, 4.7 shows the site map correctly and Seamonkey is blank.

To see what the site map is supposed to look like, enter
http://www.realworld.on.net/index/f_graphic.html  This is the none flash-enabled
site.

This particular site is a good test case as it uses a lot of different technologies.

Comment 1

[Doron Rosenberg (IBM)]

plug-ins

Comment 2

[av (gone)]

The HTML code looks a bit wrong to me. The page in question is 
http://www.realworld.on.net/index/flashmenu.html

If you look at it you will see close to the bottom commented out opening object 
tag but the params of this tag are not commented out as is not its closing part 
</object>. After I fixed this, it all works.

So this is either invalid or goes to the parser (?) Harish? The question is: 
should we mark the kind of bugs with mistakes in the html code invalid given it 
works in 4.x?

Comment 3

[dbragg]

That's a very good question for the marketing folks.  My vote is we shouldn't
mark them invalid.  The Realworld site is one of the more savvy sites and if its
got errors then other sites are bound to have even more of them.

Comment 4

[av (gone)]

Adding ekrock.

Comment 5

[av (gone)]

Attachment: Original html code

Comment 6

[av (gone)]

Attachment: Fixed html code

Comment 7

[av (gone)]

The only alteration I made to the code in the above attachments (beside fixing 
html errors) is adding the full path to the flash movie file, so it actually 
shows it out of this local html file.

Comment 8

[ekrock's old account (dead)]

It all depends on (1) available resources for this fix, (2) what other work we'd 
have to give up to get the fix in (crashers?), (3) risk of this fix. Since it's 
bad HTML that could be fixed, we could live with this for RTM if we have to, but 
we would like to fix it if we can (without much risk or time to fix) since 
there's probably lots of **** HTML out there like this. flash,evangwanted,4xp.

Comment 9

[harishd]

Attachment: Further reduced case

Comment 10

[harishd]

Attachment: Proposed patch [ IMO, it's safe ]

Comment 11

[harishd]

Attachment: Proposed patch [ IMO, it's safe ]

Comment 12

[harishd]

Since, the patch is safe (IMO), nominating for rtm.

Comment 13

[Nisheeth Ranjan]

Flash player is a high profile partner and this is a high profile backward
compatibility bug.  Increasing priority to P1.  Marking rtm+.

Comment 14

[Phil Peterson]

PDT marking [rtm need info] since this patch needs code reviews.

Comment 15

[vidur (gone)]

a=vidur (and from what Harish tells me, r=jst). The patch itself is safe and 
should be accepted if it fixes the bug. 

I'm not sure I understand what we were doing with the orphaned PARAM elements 
without the patch - I would have though that they'd become innocuous leaf 
elements. A longer term solution would not be BODY specific.

Comment 16

[Nisheeth Ranjan]

Marking rtm+ to get back onto the PDT radar.  jst and vidur have reviewed and
approved it respectively.

Comment 17

[Phil Peterson]

PDT marking [rtm++]

Comment 18

[harishd]

Fix is in the branch & trunk. Marking FIXED.

Comment 19

[shrirang khanzode]

Looks good on windows branch build 2000101208. Adding vtrunk keyword.

Comment 20

[Doron Rosenberg (IBM)]

verified win32 2000101704, removing vtrunk keyword per asa