Bug Tracker

Modify

Ticket #2037 (closed bug: fixed)

Opened 5 years ago

Last modified 14 months ago

using innerHTML can cause css display errors in Opera

Reported by: davidserduke Owned by:
Priority: minor Milestone: 1.2.2
Component: core Version: 1.2.1
Keywords: opera display innerHTML Cc:
Blocking: Blocked by:

Description

There are times when setting innerHTML can cause the css display value to be incorrect in Opera. This is a rather convoluted issue and one specific case has been identified and is shown in the attached test case.

Basically, when a div structure like this exists

<style type="text/css">
  #hid { display:none; }
</style>
<div id="container" style="display:none;">
  <div>
    <div id="hid">hidden</div>
  </div>
</div>  

and you set the innerHTML (yes you set it to itself):

$("#container")[0].innerHTML = $("#container")[0].innerHTML;

it can cause the display value from .css() to give improper results on the inner div. In this case, #hid should be display:none but instead it returns display:block.

There are many things that appear to be required so far to cause the bug including the #container div must be display:none or an ancestor must be. There must be a div between the #container and the #hid. The #hid must be display:none through a cascade in the stylesheet and cannot be style="display:none;". And, of course, it only happens in Opera. There may be other criteria or cases too but this is the only one I've found so far.

Interestingly there is a way to fix it as well by doing

var elem = $("#hid")[0];
var save = elem.style.display;
elem.style.display = "block";
elem.style.display = save;

Clearly this should just set the display to block then immediately reset to the original value. It has the consequence of "fixing" the Opera problem though such that the .css() value becomes "none" again as it should be.

No one has reported this bug in a real-life instance. It was found in the test suite which is constantly reseting the innerHTML of the test area thus giving the problem a chance to surface which it did. At this time it is not clear what the best fix is so we are opening a ticket for it.

Attachments

jquery_test.html Download (1.5 KB) - added by davidserduke 5 years ago.
test case
2037.diff Download (552 bytes) - added by davidserduke 5 years ago.
patch
opera-performance-fix.diff Download (598 bytes) - added by Junyor 5 years ago.
Alternative fix

Change History

Changed 5 years ago by davidserduke

test case

Changed 5 years ago by davidserduke

patch

comment:1 Changed 5 years ago by davidserduke

  • Status changed from new to closed
  • Resolution set to fixed

Fixed in [4196].

comment:2 Changed 5 years ago by dvessel

  • Status changed from closed to reopened
  • Resolution fixed deleted

Hello, I'm coming from Drupal and we are trying to get jQuery 1.2.3 in before release. I tracked a major slowdown in two instances do to this change. It's triggered when .offset() is used.

 http://drupal.org/node/210131#comment-711567

Would there be another way to fix this problem without the performance hit? This affects Opera 9.2.5 in both Mac and Windows.

Changed 5 years ago by Junyor

Alternative fix

comment:3 Changed 5 years ago by Junyor

I've attached an alternative patch that fixes the reported issue and avoids the performance problems seen in Drupal 6.

comment:4 Changed 5 years ago by Junyor

The fix was found by David Bloom ( http://my.opera.com/dbloom/) with help from fearphage ( http://my.opera.com/fearphage/).

comment:5 Changed 5 years ago by Junyor

Note: Opera's bug is fixed in Kestrel (AKA Opera 9.5), so the work-around won't be necessary there. However, the work-around I proposed should cause no performance problems.

comment:6 Changed 5 years ago by john

  • Status changed from reopened to closed
  • Resolution set to fixed

Fixed in SVN rev [4660].

Please follow the  bug reporting guidlines and use  jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.

View

Add a comment

Modify Ticket

Action
as closed
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.