I received a flash file from the design agency to incorporate on our template (Java/JSP based framework). I specified the width in the javascript flash player we have as those specified by the agency and 963x488, but in IE8 it seems the flash occupies more space than that and even though the flash content area remains small, the overall area occupied by flash is larger than the specified size. I tried the simple <object>/<embed> tags and it exhibits same behavior. Any idea if I can do something on the JSP or is it something that needs to be taken care of during creation of .swf file? I am running the latest plugin for flash and Firefox and Chrome do not have this issue.
You're saying that Flash's container is too big, right? That is, the area within which you can right-click and see a Flash context menu? If so, then your issue has nothing to do with the SWF content, plugin version, or Flash itself. The size of Flash's container is wholly determined by the HTML/CSS/JS of the embedding page, and browser behavior (like zooming, etc). So I think you'll need to post some details about the embedding code involved. You might also check against IE8 on other machines, in case there is a settings issue similar to what Alexandre commented about, though possibly involving different settings.
(The only exception, where the Flash content could be a factor, is if the Flash content is invoking a JS bridge to execute javascript calls to change the size of its own container. But even then it's still JS/HTML that has the say over container size.)
Related
I recently tried to load a tool on my phone that I develop that is hosted internally where I work.
A few things looked off, which I expected. But one particular element seemed to be extra odd.
I eventually loaded the page in Chrome on a MacBook Pro and used the "Device Toolbar" feature to render it in my Desktop browser like it would on a phone. To keep a private application private I will demonstrate with Google.com. This is what I see:
That's the body element highlighted in blue. The html element is the same.
This is what I see in my application too and explains what I'm seeing when actually using my phone.
I can't, for the life of me, understand why these elements chose this size. There is no explicit "width" for these elements, nor is there "max-width" etc. Nothing that I can see that should cause this behavior.
Can anyone explain this behavior?
UPDATE
It appears that there is some odd behavior with Dev Tools. Proper mobile testing probably shouldn't be done this way (Feel free to change my mind, Google...) but the issue stands that sometimes, the body element doesn't stretch to accommodate its content.
By default, block-level elements, including <body>, do not expand to fit their content, but rather will expand to the width of its container. See the spec for detailed information.
See this fiddle demonstrating this. If you resize the panels/window you'll see the body width changing based on the viewport, but the content width has absolutely no effect.
This SO question has more information: Why isn't <body> expanding to fit its contents?
Another issue that's not helping is related to the Chrome dev tools device toolbar. Changing the zoom, disabling and re-enabling the device toolbar and its settings can be buggy and is not always reliable. I have spent hours chasing issues that didn't actually exist because the device toolbar functionality misled me.
I'm working on a site where the client requested a video fill a div as the background. I have it in and working for myself but they keep complaining that they can't scroll. I have no issues on multiple computers scrolling. Is there some sort of common issue other than a slow machine that would cause this? Could it be a CSS issue? The staging site is here if it helps: http://arkroyal.staging.wpengine.com/
UPDATE
I am using a video hosting service and it seems this is only happening when the flash fallback is in there... I have set it to flash be default now and I can not scroll when my mouse is over it. So now I guess this is a flash issue?
I agree with user3285910's answer, however, that's not to say there isn't anything you can do about it.
When I first went I didn't not attempt to scroll, I just let the entire page load. Afterwards I checked the load times for the media, the Winsta MP4 took 27.36 seconds to load. That's in Chrome on a T1 line. I used Chrome because the webkit browsers are known for their laggy video lading.
With that information I would look at changing the preload value for the <video>. Currently it's "none". There are a lot of different approaches to preloading data and you cannot account for everyone's PC speed, bandwidth, etc.
I would recommend letting the browser determine their capabilities for you and adjusting accordingly. Usually 5-7 seconds of preload is enough to get around the jumping behavior. Here is a link to an article that goes into more detail with analysis.
After looking at the staging site, it doesn't seem to be an issue with the site itself, but more the video you are using. The video is high quality and will cause systems to slow down drastically. If this is the video they want as the BG, I would see if you couldn't get the video resolution lowered drastically, as this will cause issues in the rendering on some systems. This will also make users unable to scroll down the page, because their video card is busy trying to render the images that are being produced by the BG video.
The first time I go to this page, the positioning of the slideshow (developed using the JQuery cycle plugin) is all messed up, like this:
If I then refresh the page, it displays correctly, like this:
How can I ensure that this page displays correctly the first time it's viewed? The incorrect layout seems to happen more often with Chrome than with other browsers, though as you can see from the screenshots above it also happens with other browsers.
Thanks,
Don
Add width and height attributes to the images.
I'm guessing that the JavaScript activates before the image is loaded, it then does a couple quick computations to get the dimensions it needs, and locks them in place; all of this happens before the image is loaded and since there are no width or height attributes, the dimensions come out way off. On the reload, the image comes out of the browser cache so the dimensions are known when the JavaScript runs.
Your JavaScript runs when the DOM is ready, not when every single thing has been fully resolved and loaded. You could also try binding your slideshow to the load event rather than document.ready.
You see this in Chrome more than other browsers because Chrome is really fast and that magnifies the timing issue.
I am considering a project in which workstations, connected to a central server display various content under the control of a central timeline.
Requirements are that the kiosks could have various compositions of monitor and an extended desktop. This screen space would be use to display images, movies or various mosaics of images and movies.
For example, a machine with 3x3 monitors might be configured to display video in the lowest right four screens, a title on the top three videos and whatnot elsewhere.
I am figuring out how to create the viewer. I think that sticking to web technologies I know well would be good and using JavaScript for the timeline engine sounds easy.
As for codecs and video drivers I think I would stick with Chrome, Css3 and Html5, I think I can require Chrome and Windows 7.
There are a few concerns, though.
Will there be performance problems considering video split on different monitors on an extended desktop?
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
Thank you all.
A great solution for this is Adobe AIR. You are already talking about HTML, might as well check that out.
The nice thing is that AIR provides facilities for kiosks. Check out this link:
http://www.adobe.com/devnet/flex/articles/flex_kiosk.html
Just replace everything there that says Flex with HTML/Javascript. The platform functionality is available to both technologies.
As for stretching a browser or AIR app across multiple screens, I believe you would have to manually position the window yourself. I.e., if you maximize an app window on a multi-monitor setup, it expands to the size of the monitor only, not the entire viewable area. You likely will have to manually position/resize in Javascript.
As for using Chrome as a client, see this thread:
http://www.google.com/support/forum/p/Chrome/thread?tid=12bde481a208c4ca&hl=en
It doesn't look like Chrome supports a kiosk mode.
Browser shouldn't be a problem at all. Just remember the architecture - you'll need a server somewhere and each kiosk will be a client. Just set up a port/url for your app and there you go. Chrome has some features that allow you to prevent users from exiting the app. I forget the specifics, I believe it involves incognito mode and something
Company I work for does something a lot like this. We make 'apps' that run on iPad and another touch screen device called MSI (btw - one of the advantages here is the freedom of using different client platforms), but not in the typical Objective-C way. Theres a server with a LAMP stack and the client uses the browser.
Will there be performance problems considering video split on different monitors on an extended desktop?
I think more than multiple monitors what you really have is multiple clients. This is interactive to some degree right?
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
Yes. I don't really do artsy design and display details so I can't comment on specifics. But I don't think this is too hard - especially if all the clients are similar. Majority of this would be dictated by CSS.
EDIT - took a look a what we do on chrome. between running on start up, using kiosk mode and incognito (both can be runtime flags) and the regular F11 kind of full screen, you should be pretty much there
Will there be performance problems considering video split on different monitors on an extended desktop?
IMHO screen space does take a little toll on your video processing. You will need a relatively good video card to support such huge amount of displays. I am a user of dual screen on ATI Radeon HD 5750 (1GB), and I can do intense gaming on my main screen while read news and be on twitter on my other screen.
Will it be pixel predictable to size and stack divs so that images fit inside a physical monitor or monitor group?
DIVs can be easily styled and positioned using CSS. You can define the number of pixels for both width and height. And if you do your storyboarding and layout design, everything should fit in your window.
However the trouble for you is that I assume you're stretching the browser window across the 3x3 screen. I recommend you to instead have one browser window per display.
I've tried that Chrome can full screen on each display without exiting-full-screen-mode on the others.
I am currently developing a PHP website that has a lot of Flash components. On each page there are one or more custom Flash components embedded with swfObject, as well as sIFR navigation.
Every so often, ALL of the Flash objects on the page become unresponsive to the mouse (no hand pointer). So far I have found it happening only in Firefox 3.5.3 on Mac. I am using CSS to position everything with a specific stacking order to get around the bounding-box overlap issue - for example, the main navigation overlaps the top right corner of a big Flash component.
It works fine most of the time, however, if I click through the pages enough times in Firefox 3 on Mac, eventually I cannot "roll over" any of the Flash elements.
Does anyone know why all the Flash objects in a PHP page would stop responding to the mouse, sIFR included?
Here is the site if you want to give it a try.
This is usually a combination of putting wmode (transparent or opaque) on the Flash movie, which itself is contained in a floated element. Unfortunately it's a browser bug, but removing the wmode property should fix it.