450598 - help for query.cgi does not work properly on IE6

Status: RESOLVED WORKSFORME

(Bugzilla :: Query/Bug List, defect)

Description

[bigstijn]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 1.0.3705; InfoPath.1)
Build Identifier: Bugzilla 3.2RC1

help for query.cgi does not work properly on IE6, although bug 182082 comment 26 suggests it works for IE:


> 3) using an iframe control to mask any controls under the popup so they
won't bleed through in IE or any other browser
> I tested this with both IE6 and Firefox 1.5.x and it seems to work

I couldn't find any other list of supported browsers.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[bigstijn]

Attachment: query help in IE6

Comment 2

[Frédéric Buclin]

Confirmed using IE6 SP1 on Windows 2000 SP4. pyrzak, could you give a look?

Comment 3

[Guy Pyrzak]

The bug is caused by IE6's z-index problem (http://www.throbs.net/web/articles/IE-SELECT-bugs/). The easy fix is to switch the overlay to YUI which has a fix for this. After talking to LpSolit on IRC it seems like I've got a "make it so". This may require adding more of YUI to Bugzilla, which is fine by me.

Comment 4

[Teemu Mannermaa (:wicked)]

How odd, I did test V3 of patch in IE6 (as said bug 182082 comment 26) in IE6 and there was no problems as an iframe control was used as an overlay that hacked around this "bleeding controls on IE" problem. I wonder if something regressed between V3 and V3.2 (that was actually committed) or after bug 182082 was fixed.

I couldn't reproduce this on IE7 so "upgrade IE to latest" is a work around for this problem on XP (not sure about W2000). Also, Vista already comes with IE7 so it doesn't suffer this problem.

Pyrzak, are you going to write a "use YUI for help system" patch soon?

Comment 5

[Guy Pyrzak]

woops, I actually wrote this patch and forgot about it and perhaps deleted it by accident. I can redo it real quick or you're welcome to take the bug.

Comment 6

[Guy Pyrzak]

Attachment: Patch v1

Comment 7

[Guy Pyrzak]

Comment on attachment 341522 [details] [diff] [review]
Patch v1

oops forgot to set the iframe thing.

Comment 8

[Guy Pyrzak]

Attachment: Patch v1.1

Comment 9

[Max Kanat-Alexander]

Comment on attachment 341531 [details] [diff] [review]
Patch v1.1

Is there not any CSS that comes in YUI with container.js? I want to make sure that we get everything when we import a piece. Also, are there any bits that you have to fix in the JS to work with our directory structure? (I had to fix some stuff with the calendar stuff, as I recall, when I imported it.)

Comment 10

[Guy Pyrzak]

Comment on attachment 341531 [details] [diff] [review]
Patch v1.1

apparently the css is required so I'll add that.

Comment 11

[Teemu Mannermaa (:wicked)]

Comment on attachment 341531 [details] [diff] [review]
Patch v1.1

>Index: js/help.js
>===================================================================
>     // Only enable help if controls can be hidden
>-    if (!document.body.style)
>-        return false;

You need to do something about the comment too if you remove the check.

Does YUI really work even if browser doesn't support styling (CSS) or will it do it's own checking for this condition and return error accordingly? If so, that error should be handled .

>+                if(document.forms[i].elements[j].tagName.toLowerCase() == "select"){
>+                    YAHOO.util.Event.on(document.forms[i].elements[j].options, 'mouseover', showHelp );
>+                }

Interesting change. I didn't test this patch so I'm not sure how this additional mouseover event changes help for SELECT elements.

+    enableHelp();

Are you sure enabling help works at this time? This is called from onload instead of at this time because that way all controls will be fully loaded.

And if this call is moved here, shouldn't it be removed from onload?

>Index: template/en/default/search/search-advanced.html.tmpl
>===================================================================
>+  javascript_urls = [ "js/yui/yahoo-dom-event.js", "js/yui/container.js" "js/productform.js" "js/util.js" "js/help.js" ]

Is js/util.js still needed?

> [%# The decent help requires Javascript %]
>-<script type="text/javascript"> <!--
>+<div class="bz_default_hidden" id="query_js_help">

Document.write was used here so that help is not mentioned if JS is not enabled or supported by the browser. I guess this way also works, assuming specific CSS is supported by the browser. Do we assume this these days?

>-  else
>-    document.write("<p>Help initialization failed, no help available.<\/p>");
>+  <p>For help, mouse over the page elements.</p>

YUI doesn't always enable help so this failure notice shouldn't be removed. However, it can be rewritten if you want.

>+<script>

Type attribute is required for script elements per HTML 4.01 Transitional standard.

Comment 12

[Max Kanat-Alexander]

Not a blocker, because the help system isn't a critical thing and I think the majority if IE users are on IE7 now.

Comment 13

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).

Comment 14

[YDM]

I too got this bug but fixed myself. Doesn't the following simple change fix the problem?

(help.js, line 94)
    g_helpIframe.style.left = g_helpDiv.style.left = elemX + "px";
-   g_helpIframe.style.display = g_helpDiv.style.display = '';
+   g_helpIframe.style.display = g_helpDiv.style.display = 'block';
    g_helpIframe.style.width = g_helpDiv.offsetWidth + "px";

Comment 15

[Frédéric Buclin]

We removed the JS help system from query.cgi in Bugzilla 4.0, see bug 591535. The field description now simply appears in a tooltip when hovering the field label.