Closed Bug 133283 Opened 23 years ago Closed 23 years ago

show_bug.html.tmpl uses 'urlbase' variable, but it is never set


(Bugzilla :: Creating/Changing Bugs, defect)

Not set





(Reporter: ddkilzer, Assigned: ddkilzer)


(Keywords: regression)


(1 file, 1 obsolete file)

The show_bug.html.tmpl template uses a 'urlbase' variable for one
link in the HTML, but 'urlbase' is never set by show_bug() in or in show_bug.cgi.  Since none of the other HREFs
use urlbase, I'll assume it is safe to remove it.  Patch to
follow shortly.

Bug 110012 is the original show_bug.cgi templatization bug.
Target -> 2.16.  Keywords: patch, regression, review.  Add CCs.
Assign to me.
Assignee: myk → ddkilzer
Keywords: patch, regression, review
Target Milestone: --- → Bugzilla 2.16
Attached patch Patch v.1 (obsolete) — Splinter Review
Removes "[% urlbase %]" from show_bug.html.tmpl.
I'm sure we did this a while back to make right-click "bookmark this link" and
drag-to-bookmark work right - but now I think about it, they should work anyway,
shouldn't they?

urlbase should be equal to Param('urlbase')...

I guess my point is that if we are going to use 'urlbase' in front
of one HREF, we should use it in front of all of them.  I thought
it would be simpler just to remove this one instance of it so that
this HREF would be like all the others in this template.

If we'd rather set urlbase in or in, let
me know (which one).
Comment on attachment 75980 [details] [diff] [review]
Patch v.1

Right. I found what it was - bug 53951. If you save show_bug.cgi locally, it
makes the bug number an absolute link to take you back to the current version.

So, we need to keep it, and populate 'urlbase' with the Param.

Attachment #75980 - Flags: review-
Attached patch Patch v.2Splinter Review
Add 'urlbase' to template variables rather than change
template to remove 'urlbase' output.
Attachment #75980 - Attachment is obsolete: true
+    # Used by initial link to bug itself on the web page
+    $vars->{'urlbase'} = Param('urlbase');

That comment took me quite a while to understand. We could either eliminate it,
or say something like:

# We make the bug number an absolute link so it still works when the page is saved

I fixed this in the patch in bug 133425 as well.

Yes, I agree, that was a bad comment.  I wrote it without having
a clear description in my head.  :^)

FWIW, the issue brought up in Bug 53951 would be best fixed by
adding a BASE tag to the HEAD section of the web page like this:

  <BASE HREF="[% urlbase FILTER uri %]">

That would fix every link in the web page once it was saved from
a web browser.  This could optionally be added to every Bugzilla
web page, though I'm not sure if that would be desirable or not.

Should this bug be marked RESOLVED DUPLICATE of Bug 133425 then?
> That would fix every link in the web page once it was saved from
> a web browser.

Is that what browsers do with the BASE tag? Apply it when the file is local and
the link is relative?

I think that's a change which requires more thought than we have time for in
2.16. Let's fix it the easy way now, and think about <base> later.

Filed Bug 133549 regarding use of the BASE tag in a future release
of Bugzilla.
Different approach to fix this bug was included in Patch v.2 of
Bug 133425.  Marking RESOLVED DUPLICATE.

*** This bug has been marked as a duplicate of 133425 ***
Closed: 23 years ago
Resolution: --- → DUPLICATE
clearing milestones on DUPLICATE/WONTFIX/WORKSFORME/INVALID bugs (so they'll
show up as needing triage if they get reopened)
Target Milestone: Bugzilla 2.16 → ---
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.