combo boxes *jump* to top-most option when you click their label

[trac@…]

• Start a new ticket
• In any combo box (eg. Type: ), select an option part way down the list (eg. "enhancement")
• Then afterwards, whenever you click the combo box's label (ie. "Type:" ), the combo box's value jumps to the top-most option (ie. "defect")

(would be better not to 'focus' at all rather than change the value unexpectedly)

(nb. I'm using Internet Explorer 6.0)

[Matthew Good]

This is an IE bug when you use <label for="id"> with a select box: ​http://support.microsoft.com/default.aspx?scid=kb;en-us;314279

They provide a JavaScript workaround which should be possible to integrate.

Note: Please use [[BR]] sparingly. For normal text use a blank line to separate paragraphs.

[Matthew Good]

Are there any IE7 users that can verify whether this has been fixed for that version? I'd like to know whether I need to do this for all IE versions or not.

[grantj@…]

Replying to mgood:

Are there any IE7 users that can verify whether this has been fixed for that version? I'd like to know whether I need to do this for all IE versions or not.

IE7 exhibits the correct behavior (i.e. does not change the combo box value).

[Matthew Good]

Replying to grantj@lunainnovations:

Replying to mgood:

Are there any IE7 users that can verify whether this has been fixed for that version? I'd like to know whether I need to do this for all IE versions or not.

IE7 exhibits the correct behavior (i.e. does not change the combo box value).

Thanks. I'll enable the fix for IE versions prior to 7.

[Matthew Good]

The IE workaround has been added in r4848.

[jasminlapalme@…]

This bug seems to be there again. I'm working with firefox (linux and mac) and Safari(mac). Is it a bug or a feature? Is there a way to eliminate that behaviour.

[osimons]

Replying to jasminlapalme@mac.com:

This bug seems to be there again. I'm working with firefox (linux and mac) and Safari(mac). Is it a bug or a feature? Is there a way to eliminate that behaviour.

Tested on current 0.11b1+, and no issues with Firefox or Safari on Mac for me. Could you please provide information on exactly how I can reproduce this, and what version of Trac and browsers you are using?

[jasminlapalme@…]

Tested on current 0.11b1+, and no issues with Firefox or Safari on Mac for me. Could you please provide information on exactly how I can reproduce this, and what version of Trac and browsers you are using?

I'm the current 0.11 (r6414). To reproduce, Ijust do the same thing as it was said at the beginning of the ticket.

I did find the html line that is causng that. In the "new ticket" html source code, the line <script type="text/javascript" src="js/ie_pre7_hacks.js"> is there. If I remove this line, it's ok.

By the way, my trac server is on OS X Leopard.

[Christian Boos]

Strange, how come this was a 0.11 ticket?

[Tim Hatch]

eblot, osimons, and I all noticed this on t.e.o as well. I can't reproduce with 0.11b1, 0.11b2, or current trunk on localhost or a remote host. I grabbed a set of js files from e.o's chrome/common11 and they look identical to my copy. I tried Safari/Mac, Firefox/Mac, and Firefox/Linux. They all exhibit the behavior on t.e.o, but not on my local env's.

[Christian Boos]

I can't reproduce the issue locally either, but it's definitely there for t.e.o. Note that t.e.o pages come with a batch of google js (urchin.js, graphics.js, show_ads.js, …) so I think the problem comes from there.

[Emmanuel Blot]

Replying to cboos:

I can't reproduce the issue locally either, but it's definitely there for t.e.o. Note that t.e.o pages come with a batch of google js (urchin.js, graphics.js, show_ads.js, …) so I think the problem comes from there.

As I wrote in ticket:7077:1, this is not a t.e.o. -only issue: I experience the same trouble on a local installation.

I would rather target this issue for 0.11 as it's really easy to mess up with a ticket without even noticing it.

[Christian Boos]

Replying to eblot:

Replying to cboos:

I can't reproduce the issue locally either, but it's definitely there for t.e.o. Note that t.e.o pages come with a batch of google js (urchin.js, graphics.js, show_ads.js, …) so I think the problem comes from there.

As I wrote in ticket:7077:1, this is not a t.e.o. -only issue: I experience the same trouble on a local installation.

Good, so you're the one in the better position to fix it then :-) Even with Safari 3.1, this works as expected for me. Any plugin that might explain the difference? Or is it a platform specific issue?

I would rather target this issue for 0.11 as it's really easy to mess up with a ticket without even noticing it.

Well, at this point I think we should only target for 0.11 bugs with a clear solution at hand, or really really serious defects. Which is not to say this can't go in 0.11, if we find a fix in time.

[Emmanuel Blot]

Good, so you're the one in the better position to fix it then :-)

I wish I could, but my spare time these days is … negative ;-(

Even with Safari 3.1, this works as expected for me.

Tested on Safari 3.1 as well and … fails.

Any plugin that might explain the difference?

I use the ​th:RevTreePlugin but I don't see how it could get in the way. It uses the Trac -provided Jquery library, and a couple of routines that are not emitted but on the Revtree web pages.

Or is it a platform specific issue?

Perhaps. Let me start a VM today and I'll try with WinXP, I let you know.

Well, at this point I think we should only target for 0.11 bugs with a clear solution at hand, or really really serious defects. Which is not to say this can't go in 0.11, if we find a fix in time.

Agreed.

[Emmanuel Blot]

It seems this issue is due to the IE hack javascript.

The following patch works for me:

trac/htdocs/js/ie_pre7_hacks.js

@@ -1 +1 @@
 jQuery(function($) {  // onload
-    $('select').bind('focusin', function() {
-        this.tmpIndex = this.selectedIndex;
-    }).bind('focus', function() {
-        this.selectedIndex = this.tmpIndex;
-    });
+    if ( $.browser.msie ) {
+        $('select').bind('focusin', function() {
+            this.tmpIndex = this.selectedIndex;
+        }).bind('focus', function() {
+            this.selectedIndex = this.tmpIndex;
+        });
+    }
 });
+

"works":

1. fix up the trouble with Safari
2. I don't experience more issue with IE than usual, although I usually try to avoid IE as much as possible. It means that I'm not able to reproduce the issue w/ IE 6.x, I don't (and won't) have IE 7: the initial issue reported by 'trac@…' may not be addressed with this patch

[Emmanuel Blot]

Replying to eblot:

It seems this issue is due to the IE hack javascript.

Any feedback ?

[trac@…]

We have also ran into this trouble with:

• beta1 on Win XP
• beta2 on Win XP
• dev_r6473 OS X 10.4
• dev_r6886 OS X 10.4
• this t.e.o instance!

and browsers:

• Safari 3.1
• Firefox 2.0.0.14 (OS X 10.4)
• Firefox 2.0.0.14 (Win XP SP2)
• basically anything not IE

Whilst the fix above (comment:19) is also working for us, a much better way to target IE 6/7/8 problems would be to use ​IE conditional comments to only include the JS/CSS files for the exact versions of IE being fixed.

I believe this should be fixed urgently as it leads directly to mis-input/corruption of data (like accidentally changing ticket priorities).

[Christian Boos]

Well, trouble is that the inclusion of that file should already be conditioned by conditional comments: source:trunk/trac/templates/layout.html@6895#L25​

For some reason, it doesn't work. If this would have worked, the $.browser.msie test in comment:19 wouldn't be needed.

This must be related to ​#G94 and that also explains why I can't reproduce the bug: I don't use a site.html.

The following part of your site.html should be modified from:

  ...
  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*')}
    <link rel="stylesheet" type="text/css"
          href="${href.chrome('site/style.css')}" />
  </head>
  ...

(as taken from TracInterfaceCustomization@50)

to:

  ...
  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*|comment()')}
    <link rel="stylesheet" type="text/css"
          href="${href.chrome('site/style.css')}" />
  </head>
  ...

as explained in ​#G94.

[Christian Boos]

#7151 closed as duplicate (don't forget to test the use-case described there once t.e.o 's site.html is updated).

[anonymous]

The fix in comment:ticket:3774:21 did not work for me. I had to add |text() as well.

Please also remember to fix the site.html template in 0.11/TracInterfaceCustomization, otherwise it is to be foreseen that numerous other users will fall prey to this annoying and hard-to-find bug.

[anonymous]

sorry, typo - meant comment:ticket:3674:21, of course.

[Christian Boos]

Replying to anonymous:

The fix in comment:ticket:3774:21 did not work for me. I had to add |text() as well.

Thanks for the update! So the right setting should be:

  ...
  <!--! Add site-specific style sheet -->
  <head py:match="head" py:attrs="select('@*')">
    ${select('*|comment()|text()')}
    <link rel="stylesheet" type="text/css"
          href="${href.chrome('site/style.css')}" />
  </head>
  ...

Please also remember to fix the site.html template in 0.11/TracInterfaceCustomization, otherwise it is to be foreseen that numerous other users will fall prey to this annoying and hard-to-find bug.

Sure, I was waiting for someone to test the proposed fix before doing so, see TracInterfaceCustomization@51 (the 0.11/… pages will be synchronized after the release).

Setting the status to fixed as per comment:6.