History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-5056
Type: Bug Bug
Status: Open Open
Priority: P1 P1
Assignee: Max Carlson
Reporter: Max Carlson
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
OpenLaszlo

history not working correctly in IE 6

Created: 07/Nov/07 01:57 PM   Updated: Monday 12:19 PM
Component/s: HTML Wrappers
Affects Version/s: Cranberry
Fix Version/s: 4.2.1

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive testiframe.zip (400 kb)


Severity: Minor
Runtime: N/A
Fix in hand: False


 Description  « Hide
See the testcase in LPP-4999.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Max Carlson - 07/Nov/07 02:07 PM
Attaching a version of the testcase that works around the issue in IE 6.

Max Carlson - 07/Nov/07 02:19 PM
Fix found by promanik:

This page discusses the problem in detail, but since I don't understand the details of how the flash is embedded, can you take it from here?

http://www.ryangorer.com/blog/2007/10/12/setting_url_hash_value_from_flash.html
http://www.ryangorer.com/blog/files/20071012_setting_url_hash_value_from_flash_parent.html

Normally, calling a JavaScript function from Flash acts the same way as it would if you were to call the JavaScript function from a button on the web page itself, for instance. However, there is a bug in Internet Explorer 6 which causes it to mishandle the setting of the page hash when the JavaScript function is being called from Flash. Firefox and Safari process this function from Flash just fine; go figure.
In order to get this function to work in IE6, you have to embed the Flash application into an IFrame. Then, the Flash application calls a JavaScript function which sets the value of "parent.location.hash" instead of "window.location.hash". Thankfully, this technique also works in Firefox and Safari, so getting this functionality to work in all browsers can be accomplished using a single approach.

The attached workaround embeds the app in an iframe in ie 6 - see index.html in the attached testcase (testiframe.zip).

Max Carlson - 07/Nov/07 03:22 PM
This version works around the issue without requiring a separate html file to be loaded by the iframe...

Max Carlson - 07/Nov/07 03:25 PM
Here's the essence of the fix:

<script type="text/javascript">
              if (Lz.__BrowserDetect.isIE && Lz.__BrowserDetect.version < 7 && window.top == window) {
                // write out a top-level iframe for IE 6 only - see lpp-5056
                var loc = window.location + '';
                // take everything after the last '/', up to the hash mark
                loc = loc.substring(loc.lastIndexOf('/') + 1, loc.lastIndexOf('#'));
                // Add a string to bust the cache in the embedded iframe and ensure it loads...
                if (loc.indexOf('?') == -1) {
                    loc += '?'
                } else {
                    loc += '&'
                }
                loc += 'cachebuster=' + (new Date()).getTime()
                // add the original hash, if any
                loc += window.location.hash;

                // write out an iframe that points back to this URL
                document.write('<iframe src="' + loc + '" width="99%" height="99%" frameborder="no"></iframe>');
              } else {
                Lz.swfEmbed({url: 'test.lzx.lzr=swf8.swf?lzproxied=false', bgcolor: '#ffffff', width: '100%', height: '100%', id: 'lzapp', accessible: 'false'});
              }
            </script><noscript>
            Please enable JavaScript in order to use this application.
        </noscript>

Amy Muntz - 07/Nov/07 06:31 PM
Make sure to get this workaround in the Release Notes.