Edgewall Software
Modify

Opened 18 years ago

Closed 16 years ago

#3674 closed defect (fixed)

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

Reported by: trac@… Owned by: Christian Boos
Priority: highest Milestone: 0.11
Component: general Version:
Severity: normal Keywords: javascript
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description (last modified by Matthew Good)

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

Attachments (0)

Change History (25)

comment:1 by Matthew Good, 18 years ago

Description: modified (diff)
Owner: changed from Jonas Borgström to 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.

comment:2 by Matthew Good, 17 years ago

Keywords: needinfo added
Milestone: 0.10.1

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.

in reply to:  2 ; comment:3 by grantj@…, 17 years ago

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

in reply to:  3 comment:4 by Matthew Good, 17 years ago

Status: newassigned

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.

comment:5 by Matthew Good, 17 years ago

Keywords: combo box needinfo removed

comment:6 by Matthew Good, 17 years ago

Milestone: 0.10.40.11
Resolution: fixed
Status: assignedclosed

The IE workaround has been added in r4848.

comment:7 by jasminlapalme@…, 16 years ago

Resolution: fixed
Status: closedreopened
Version: 0.9.6devel

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.

in reply to:  7 ; comment:8 by osimons, 16 years ago

Keywords: needinfo added

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?

in reply to:  8 comment:9 by jasminlapalme@…, 16 years ago

Component: generallog view

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.

comment:10 by jasminlapalme@…, 16 years ago

Component: log viewgeneral
Keywords: needinfo removed

comment:11 by Christian Boos, 16 years ago

Milestone: 0.110.11.1

Strange, how come this was a 0.11 ticket?

comment:12 by Tim Hatch, 16 years ago

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.

comment:13 by Christian Boos, 16 years ago

Component: generalproject
Milestone: 0.11.1not applicable
Owner: changed from Matthew Good to Christian Boos
Status: reopenednew
Version: devel

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.

in reply to:  13 ; comment:14 by Emmanuel Blot, 16 years ago

Milestone: not applicable0.11.1

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.

comment:15 by Emmanuel Blot, 16 years ago

Severity: minornormal

in reply to:  14 ; comment:16 by Christian Boos, 16 years ago

Component: projectgeneral
Keywords: javascript added

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.

in reply to:  16 comment:17 by Emmanuel Blot, 16 years ago

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.

comment:18 by Emmanuel Blot, 16 years ago

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

The following patch works for me:

  • trac/htdocs/js/ie_pre7_hacks.js

     
    11jQuery(function($) {  // onload
    2     $('select').bind('focusin', function() {
    3         this.tmpIndex = this.selectedIndex;
    4     }).bind('focus', function() {
    5         this.selectedIndex = this.tmpIndex;
    6     });
     2    if ( $.browser.msie ) {
     3        $('select').bind('focusin', function() {
     4            this.tmpIndex = this.selectedIndex;
     5        }).bind('focus', function() {
     6            this.selectedIndex = this.tmpIndex;
     7        });
     8    }
    79});
     10

"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

in reply to:  18 comment:19 by Emmanuel Blot, 16 years ago

Replying to eblot:

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

Any feedback ?

comment:20 by trac@…, 16 years ago

Priority: normalhighest

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

comment:21 by Christian Boos, 16 years ago

Milestone: 0.11.10.11

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.

comment:22 by Christian Boos, 16 years ago

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

comment:23 by anonymous, 16 years ago

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.

comment:24 by anonymous, 16 years ago

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

in reply to:  23 comment:25 by Christian Boos, 16 years ago

Resolution: fixed
Status: newclosed

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.