422392 - flash map is not displayed

Status: VERIFIED WORKSFORME

(Camino Graveyard :: Annoyance Blocking, defect)

Description

[mkosnik+bugzilla]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.14pre) Gecko/20080312 Camino/1.6b3pre (like Firefox/2.0.0.14pre)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:1.8.1.14pre) Gecko/20080312 Camino/1.6b3pre (like Firefox/2.0.0.14pre)

map not being displayed in camino - works in other (Safari,Mozilla) browsers - not even displaying a flash bubble to click.  This used to work - but has broken since I started using this build... I *think* it worked in the 20080303 nightly build (it worked in the last nightly I had installed, but I am not certain of the date of the build).

Reproducible: Always

Steps to Reproduce:
1. open url.
2.
3.
Actual Results:  
map is not displayed.

Expected Results:  
map is displayed in all other browsers.

This could well be a flash plugin issue, but given that it has worked with this version of flash - and other flash elements on the same page do render I am classing it a page layout issue.

I am running 10.5.2 - patched to current.
Shockwave Flash 9.0 r115
Camino Version 1.6b3pre (1.8.1.14pre 2008031200)

Comment 1

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This seems to be related to Flashblock, and probably the fix we took in bug 418489.

I haven't had time to look in more detail, but disabling "Block Flash animations" allows the map to show.

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(That is, when Flashblock is enabled, there's no "click to play"; when Flashblock is off, the map is there.)

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

If it is bug 418489 and if Philip doesn't have another clever trick up his sleeve, we should probably back out bug 418489, since having a "click-to-play" icon that doesn't work right is better than not having the icon at all (and thus not knowing that Flashblock was blocking something).

Comment 4

[Philip Chee]

In Firefox 2.0.0.13pre I can see the flashblock placeholder if I scroll to the extreme right. Once I click on the placeholder the flash object appears in the right location.

This also happens in Firefox 1.5. Minefield displays the placeholder in the correct location.

I believe that this is due to reflow bugs in the 1.8.0/1.8.1 branch. The reason that the flash object (once activated) is located correctly is that objects are replaced elements and should be displayed as inline-block. On branch inline-block is not implemented and object placement is faked by some layout magic. On trunk our placeholder uses "display: inline-block" so it shows up in the correct location.

This analysis is based on similar bugs reported previously in our bugzilla. Better theories welcome.

Comment 5

[Philip Chee]

> If it is bug 418489

If you scroll as far right as possible, do you see the placeholder in Camino?

Comment 6

[mkosnik+bugzilla]

Yes...  the flash block is being drawn way to the right (above a full page over).  I had not seen it before I went looking for it at your suggestion.

Comment 7

[mkosnik+bugzilla]

also... once the blocker "play" button is pressed then the map is drawn in the correct location on the page

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Yeah, this is not a regression from bug 418489 (or probably anything else--except maybe some NYT markup change, if it worked before).  I checked a series of old nightlies from before bug 418489 and it appeared broken in all of them.

Given comment 4, I think the proper resolution of this is "WFM on the trunk" (or a dupe of one of the other bugs Philip alludes to, if you have any handy).

It's unfortunate that the placeholder appears displaced so far out in un-obvious territory, but there doesn't seem to be anything we can reasonably do here on the branch.

Comment 9

[Philip Chee]

> (or a dupe of one of the other bugs Philip alludes to, if you have any handy).

Unfortunately that's bugzilla on mozdev. I think leaving it as WFM would be OK.

> It's unfortunate that the placeholder appears displaced so far out in
> un-obvious territory, but there doesn't seem to be anything we can reasonably
> do here on the branch.

Yes. One reason things work on trunk is the massive refactoring of the layout/reflow code. Not exactly back portable I don't think.