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

CommentFileSizeAuthor
#5 history_remote.patch623 bytesjohn bickar
#5 tabs.patch436 bytesjohn bickar

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

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.

Ivis’s picture

Ivis commented

Adding src="javascript:false;" in the iframe definition of in jquery.history_remote.min.js also seems to solve the problem.

john bickar’s picture

john bickar commented

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.)

john bickar’s picture

john bickar commented
Version: 5.x-1.x-dev » 5.x-1.1
john bickar’s picture

john bickar commented
StatusFileSize
new tabs.patch436 bytes
new history_remote.patch623 bytes

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)

  1. Dowload and unzip the jQuery History/Remote plugin
  2. Copy jquery.history_remote.js to the jstools/ directory (in sites/all/modules/ if that's where you installed it)
  3. Apply the history_remote.patch patch that's attached here
  4. Apply the tabs.patch patch that's attached here
  5. Profit?
willdashwood’s picture

willdashwood commented

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.

john bickar’s picture

john bickar commented

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.

willdashwood’s picture

willdashwood commented

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!

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Active » Fixed

I made the history-remote plugin optional, defaulting to disabled.

john bickar’s picture

john bickar commented
Version: 5.x-1.1 » 5.x-1.2
Status: Fixed » Active

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!

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

@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.

john bickar’s picture

john bickar commented

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".

  1. (re: testing) Agreed. I can work on this in the next couple of days, pending your responses to #2 and #3, below.
  2. This issue also has been reported and addressed in Drupal core. It was marked as "won't fix" as it is an IE bug and not a Drupal bug, therefore the "fix" is technically a workaround rather than a bug fix. If you choose to take this stance, I would not have a problem with it.
  3. You make a good point regarding modifying a library that you neither write nor maintain. Would it make sense to file a bug report for history_remote and change this issue to "postponed" until the external library that JSTools relies upon is updated? (I can file the history_remote bug report.)

Thanks,

cubbtech