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

Status: RESOLVED DUPLICATE of bug 133425

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[David D. Kilzer (ddk)]

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
bug_form.pl 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.

Comment 1

[David D. Kilzer (ddk)]

Target -> 2.16.  Keywords: patch, regression, review.  Add CCs.
Assign to me.

Comment 2

[David D. Kilzer (ddk)]

Attachment: Patch v.1

Removes "[% urlbase %]" from show_bug.html.tmpl.

Comment 3

[Gervase Markham [:gerv]]

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

Gerv

Comment 4

[David D. Kilzer (ddk)]

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 globals.pl or in bug_form.pl, let
me know (which one).

Comment 5

[Gervase Markham [:gerv]]

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.

Gerv

Comment 6

[David D. Kilzer (ddk)]

Attachment: Patch v.2

Add 'urlbase' to template variables rather than change
template to remove 'urlbase' output.

Comment 7

[Gervase Markham [:gerv]]

+    # 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

Gerv

Comment 8

[Gervase Markham [:gerv]]

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

Gerv

Comment 9

[David D. Kilzer (ddk)]

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?

Comment 10

[Gervase Markham [:gerv]]

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

Gerv

Comment 11

[David D. Kilzer (ddk)]

Filed Bug 133549 regarding use of the BASE tag in a future release
of Bugzilla.

Comment 12

[David D. Kilzer (ddk)]

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 ***

Comment 13

[Dave Miller [:justdave]]

clearing milestones on DUPLICATE/WONTFIX/WORKSFORME/INVALID bugs (so they'll
show up as needing triage if they get reopened)