flex-users / flex-iframe

IFrame component for Flex applications.
github.com/flex-users/flex-iframe
120 stars 63 forks source link

IFrame is positioned wrong. #53

Closed nicoulaj closed 13 years ago

nicoulaj commented 13 years ago

Originally filed by andr....@gmail.com on 2009-11-09T10:31:10

Sometimes IFrame seemes to be shifted. For example, when flex application takes all the screen and IFrame has about 1/4 of width and positioned on the right side of the app. In this case IFrame is shifted to the right on a couple pixels...

I've attached example application. When you see red background near IFrame it means that IFrame positioned wrong.

It concerned with calculating error when browser scale is calculated... I've seen it even when the scale was set to 100%.

Issue appeared in IE7. Just checked with the Firefox 3.5 - issue is not reproduced. So, looks like that for IE browser size determined incorrectly. Maybe the the size with borders is taken?

I'm not an expert in javascript, so I don't know what variables should be used. I just can suggest to measure not the whole browser window and the whole flex application but size of IFrame container in flash and size of IFrame element on the page... Possibly this values should be the same for all browsers...

nicoulaj commented 13 years ago

Updated by andr....@gmail.com on 2009-11-09T13:02:29

I think we should compare calculate scale using the size of the flash object. So caompared to the current implementation difference will be just in the getBrowserMeasuredWidth function. The only issue is the id of the flash object... If there are more than one flash files embedded it can be difficult to determine which object to use. I think we should pass the flash object ID to the IFrame from outside, I mean from the main flex app.

nicoulaj commented 13 years ago

Updated by Julien.N...@gmail.com on 2009-11-09T13:17:31

For the id of flash object, this is a easy because we already have a function that resolves it when the iframe is created. See there: http://code.google.com/p/flex-iframe/source/browse/trunk/flexiframe/src/com/google/code/flexiframe/IFrame.as#968

For the way the scale is calculated: you are totally right, here is how the scale is calculated: browser width / Flex application measured width

It means that if the Flex application does not have a 100% width, this is wrong. This should be: Browser measured width for SWF object / Flex application measured width

The thing is, to detect the zoom ratio, we can only use the JavaScript variables that get "tricked" by the browser zoom and fluctuate with it. If you take a look here ( http://code.google.com/p/flex-iframe/source/browse/trunk/flexiframe/src/com/google/code/flexiframe/IFrameExternalCalls.as#388 ), you can see it is not the same for every browser.

Maybe using document.getElementById(SWFObjectID).width instead would give the good value... But I really don't have the time to test, sorry...

The thing is to find what variables to compare to get the correct zoom ratio for every browser.

nicoulaj commented 13 years ago

Updated by andr....@gmail.com on 2009-11-09T13:40:51

Oh, great function! Very cool idea with random string :)

And document.getElementById(SWFObjectID).offsetWidth - is a cross-browser solution according to http://www.quirksmode.org/dom/w3c_cssom.html#elementview. And I've tried it by myself with IE7 and firefox 3.5. So, I think we can use it with safety.

nicoulaj commented 13 years ago

Updated by Julien.N...@gmail.com on 2009-11-09T13:52:18

Ok, cool, I'll check on that.

Still, after taking a second lecture to this issue, I'm not very optimistic it will solve it totally. The few pixels are due to the fact that we do a*b/c calcul, and it ends with an approximation :s But it should not be the case when the zoom ratio is 1 (common case). May be we should just round the calculated zoom ratio.

nicoulaj commented 13 years ago

Updated by andr....@gmail.com on 2009-11-09T14:19:29

Yes, approximation is not good... When I've tried this solution I've periodically seen red lines around the IFrame. Rounding can help, but we can't be sure in what side to round... Ideally, we should use browser's mechanism of scale to detect coordinates, but I think it is almost impossible due to different technique of each browser... But I think 1 extra-pixel is not so much, and we can go with it...

nicoulaj commented 13 years ago

Updated by Julien.N...@gmail.com on 2009-11-09T14:33:48

We could consider most browsers zoom step by step, I mean their zoom ratio are like 1, 1.2, 1.4 ... I don't know any browser that does "smooth" zooming. I this case there is no danger rounding, let's say to 0.05.

nicoulaj commented 13 years ago

Updated by andr....@gmail.com on 2009-11-09T15:45:33

In IE usual steps are 100%, 125%, 150%. For 150% scale is 0,666666(6)... Rounding of such number can cause more mistake than without rounding. I thought about rounding of the values which we get after multiplication of width to scale. We should get integer (pixel number), but it is usually float. Maybe we should round it to the closest int? But it should be already rounded somewhere... Maybe we should control it by ourself...

nicoulaj commented 13 years ago

Updated by Julien.N...@gmail.com on 2009-11-09T15:56:37

Ho yeah, forget what I said.

In the actual version we don't round it, see this line: http://code.google.com/p/flex-iframe/source/browse/trunk/flexiframe/src/com/google/code/flexiframe/IFrame.as#516 But it should be only a more or less 1 pixel error. The fact is it is more.

As you said earlier, I think this is due to the fact we measure the window + its border with offsetWidth. I'll give a shot at your idea on comment 3 first.

nicoulaj commented 13 years ago

Updated by Julien.N...@gmail.com on 2009-11-09T19:14:08

OK, I used the solution of comment 3 + rounding. Now we have a maximum shift of 1 pixel, only when zooming in. I don't think we can do better than that, so I consider it as fixed. Thanks for the help andr.fel ;)

nicoulaj commented 13 years ago

Updated by Julien.N...@gmail.com on 2009-11-09T19:14:54

Original ticket set status to Fixed (we converted to closed)

nicoulaj commented 13 years ago

Updated by andr....@gmail.com on 2009-11-10T08:11:44

Thanks to you :)