| Project: | Javascript Tools |
| Version: | 5.x-1.2 |
| Component: | Tabs |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Issue Summary
There is a tiny little problem - but still a very annoying one ;-).
If you use tabs with IE6 and https-connection, you get warnings (every click) about unsecure objects on the page. This is due to an iframe in jquery.history_remote.min.js (took me quite a while to find the guilty one ;-)). Okay - my quick solution:
tabs.module, Line 119:
//drupal_get_path('module', 'jstools') . '/jquery.history_remote.min.js', It seems to run fine! Maybe there are problems - but as long as i tried it - it still runs fine - only loosing the history functionality.
I already made an entry at the page of stilbuero - but for the drupal part - maybe there could be a management option, to deactivate history-functions in tabs - or even it could be deactivated only for IE6-Browsers by default, when using https? Or a management-option to deactivate it only on ie6....
regards
Christian
Comments
#1
Thanks for noting this issue. Not sure what the best solution is. I suppose making history optional would be useful. I'd welcome a patch.
#2
Adding src="javascript:false;" in the iframe definition of in jquery.history_remote.min.js also seems to solve the problem.
#3
Subscribing. I will look into this see if I can proffer a patch.
(The security warning is "This page contains both secure and nonsecure items. Do you want to display nonsecure items?" I'm adding it here because I didn't find this issue when I used that in my search query.)
#4
#5
Here's a workaround, using the src="javascript:false;" fix suggested by Ivis.
BTW, this is a known bug in IE since at least version 4.
This solution does not re-pack the javascript, so you're adding an additional 8KB to the file size of your page (jquery.history_remote.pack.js = 8KB, jquery.history_remote.js=16KB)
#6
I've got an ubercart store which had this problem and I've only just managed to find out that this is the culprit for the warning messages. What does jquery.history_remote.pack.js actually do and is it safe to just remove it? I only use tabs in a basic way on the home page of the site.
#7
jQuery History Remote enables bookmarking and the use of the browser's forward and back buttons to navigate from tab to tab. When I go to your homepage and click one of the tabs, then hit the back button in my browser, it takes me to the previous tab, not the previous page. (At least that's what it did this morning. It looks like you've disabled jquery.history_remote.)
If you're satisfied with the functionality as it is now, then you can remove jquery.history_remote.pack.js.
#8
Thanks yes, I can live with the ability to navigate to previous tabs with the browser controls so I just removed it and all is well. Thanks!
#9
I made the history-remote plugin optional, defaulting to disabled.
#10
Thanks for making the update! It is nice to have the option to turn off history remote if you don't want/need it, and that does do away with the IE security warnings.
A minor quibble, however: if you do want the history remote functionality (I do), and you turn that feature on, the IE security warnings persist. That bug can be fixed by unpacking the jquery.history_remote.pack.js and adding a src attribute to the
<iframe>tag as detailed in comment # 2 and comment #5.Feel free to change this to "feature request" or "won't fix" as you see fit.
Thank you!
#11
@cubbtech: Thanks for following up.
Your proposed patch sounds promising. Because this library isn't one I wrote, and because I don't understand much about IE and its iframe handling, I can't say with confidence whether this patch would have unintended consequences. Before applying this patch, I'd like to see some or ideally all of the following:
* some solid testing results in multiple browsers on different platforms confirming that this change (a) fixes the problem in all affected versions and (b) doesn't create a new problem in any browser.
* a reference describing why this change should solve the problem.
* a packed version of the patched file.
#12
Thanks being willing to re-address this, nedjo. I will try to provide what you ask; however, in digging into this a bit more I have some details that might make this a "won't fix" or "postponed".
Thanks,
cubbtech