User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:220.127.116.11pre) Gecko/20080312 Camino/1.6b3pre (like Firefox/18.104.22.168pre) Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en; rv:22.214.171.124pre) Gecko/20080312 Camino/1.6b3pre (like Firefox/126.96.36.199pre) 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 (188.8.131.52pre 2008031200)
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.
Status: UNCONFIRMED → NEW
Component: Page Layout → Annoyance Blocking
Ever confirmed: true
QA Contact: page.layout → annoyance.blocking
(That is, when Flashblock is enabled, there's no "click to play"; when Flashblock is off, the map is there.)
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).
In Firefox 184.108.40.206pre 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.
> If it is bug 418489 If you scroll as far right as possible, do you see the placeholder in Camino?
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.
also... once the blocker "play" button is pressed then the map is drawn in the correct location on the page
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
> (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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.