BUTTON tags in template/default/attachment/edit.atml do not work with NS 4.7x

RESOLVED FIXED in Bugzilla 2.16



Attachments & Requests
17 years ago
5 years ago


(Reporter: David D. Kilzer (ddk), Assigned: David D. Kilzer (ddk))


Bugzilla 2.16



(1 attachment, 2 obsolete attachments)



17 years ago
The BUTTON tags used in template/default/attachment/edit.atml do
not work with Netscape Communicator 4.72 under Linux (RH6.2).

Recommend that they be changed to INPUT tags with TYPE="BUTTON".


17 years ago
Target Milestone: --- → Bugzilla 2.16

Comment 1

17 years ago
Created attachment 48027 [details] [diff] [review]
Proposed fix to BUTTON tags

Comment 2

17 years ago
NS 4.72 also generates a happy-fun JavaScript error:

JavaScript Error: http://HOSTNAME/attachment.cgi?id=1&action=edit, line

document.getElementById is not a function. 
My god, the page looks horrible in NS4.x.  I'm not sure how much of an
improvement it is to fix the buttons, since it fools people into thinking they
can actually do something with them, which they can't in NS4.x because it
doesn't have the necessary DOM support.  Ideally these buttons wouldn't even
show up in browsers that cannot take advantage of them.  What's the best way to
do that?
since the buttons require javascript to operate, how about dynamically inserting
them via document.write() from the javascript?

Comment 5

16 years ago
Assigning bug to myself.  Added appropriate keywords.
Assignee: myk → ddkilzer
Keywords: patch, review
Comment on attachment 48027 [details] [diff] [review]
Proposed fix to BUTTON tags

This is the wrong solution since the buttons would not work on Netscape
even if they were INPUT tags.
Attachment #48027 - Flags: review-


16 years ago
Depends on: 102957
Maybe the CGI should sniff User-Agent?
Keywords: patch, review
A horrible but working hack would be to put the buttons inside a <NOLAYER> tag pair.

What other significant browsers don't support IFRAMEs apart from 4.x? If it's
only 4.x, we can combine the noiframe stuff with the nobutton stuff.

Anyone know about the level of iframe support cross-browser?


Comment 10

16 years ago
Info about iframes support in browsers:

  http://www.htmlcompendium.org/  [Navigate in, "HTML", "Attribute Pagess",
                                   then "<iframe>"]
We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Should be a 2.16 blocker.
Severity: major → blocker
Priority: -- → P1
Target Milestone: Bugzilla 2.18 → Bugzilla 2.16
Is Lynx a supported platform for Bugzilla? It seems to be the only other browser
we might care about which doesn't support IFRAMEs. 

I think the <nolayer> hack might do for 2.16. Espcially given that it's a
template, so people can fix it another way if it doesn't work for them.

Yep, Lynx is supported.  And I just tried looking at the attachment editor
screen, and believe it or not, Lynx 2.8.3 supports IFRAME. :)  The buttons do
show up, however, they're not selectable.  But the big textarea is already
visible (however not pre-loaded with the quoted attachment).


16 years ago
Blocks: 118127


16 years ago
No longer blocks: 118127
myk: are you the man to fix this?

Yep.  The solution is to sniff for document.getElementById and document.write
those buttons if it exists, since only browsers implementing that method are
going to be able to do the DOM manipulation these features require.
Created attachment 67433 [details] [diff] [review]
patch v2: document.writes the buttons if browser implements getElementById

This version works on Mozilla and doesn't print the button text in Netscape
Attachment #48027 - Attachment is obsolete: true

Comment 18

16 years ago
Myk: Won't that generate JS strict warnings? I thought the way to check for an
implementation was 

if ( typeof(document.getElementByIdea) != "undefined" ) {
It's what I do in my JS at least :-)

Comment 19

16 years ago
-> myk 
Created attachment 67438 [details] [diff] [review]
patch v3: better way of detecting getElementById implementation

uses typeof to avoid strict JavaScript warnings
Attachment #67433 - Attachment is obsolete: true

Comment 21

16 years ago
Comment on attachment 67438 [details] [diff] [review]
patch v3: better way of detecting getElementById implementation

Attachment #67438 - Flags: review+
Checking in edit.atml;
/cvsroot/mozilla/webtools/bugzilla/template/default/attachment/edit.atml,v  <--
new revision: 1.8; previous revision: 1.7
Last Resolved: 16 years ago
Resolution: --- → FIXED


16 years ago
Component: Creating/Changing Bugs → attachment and request management
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.