22041 - Bug page TITLE should include bug summary

Status: VERIFIED FIXED

(Bugzilla :: Bugzilla-General, enhancement, P3)

Description

[Joseph Elwell]

When I bookmark a bug, all I get is the bug number. It would be useful if the
title could be the summary or possibly a new field that is editable.

Comment 1

[Dawn Endico]

I think this would be a good idea too. assigning to myself but this won't happen
till after the new year since we want to leave our servers unchanged so they'll
be as stable as possible over the holiday.

Comment 2

[Matthew Tuck [:CodeMachine]]

This was originally filed as bug #7692 which was marked a dupe of bug #3078.  I
don't think it's a dupe any longer though, this seemed to slip through the
cracks.

Anyway, adding cc of those who might be interested/have other opinions.

Comment 3

[Terry Weissman]

*** Bug 7692 has been marked as a duplicate of this bug. ***

Comment 4

[Jon Granrose]

this would certainly make build verification easier, hopefully translating into 
opening the tree slightly faster. and every little bit helps...

Comment 5

[Joseph Elwell]

I noticed that bugzilla has had at least one serious face lift since the new 
year - and still no status on this bug. Any news from endico?

Comment 6

[Dawn Endico]

I thought this would be an utterly trivial change but its not
which is why i havne't gotten to it yet.

Comment 7

[Jesse Ruderman]

I'm assuming that the reason it's non-trivial is that show_bug.cgi displays a 
bunch of html code, including the page title, before calling bug_form.pl to 
output the form and comments.  As a workaround, I suggest hacking bug_form.pl 
so that when it is called from show_bug.cgi, it outputs the following html 
along with the form and comments:

<script language="javascript">document.title = "Bugzilla bug 00000 - 
Summary";</script>

(More assumptions: you don't usually try to bookmark bugs until they're done 
loading, and you have javascript enabled.)

Comment 8

[Matthew Tuck [:CodeMachine]]

I think the hard part is that bug_form.pl is also called by process_bug.cgi.

Comment 9

[Jesse Ruderman]

there has to be some really simple hack to get around that, like setting a 
variable in show_bug.cgi to tell bug_form.pl what called it.  it might be good 
for all cgi files that call bug_form.pl to do something similar.

disc: i don't program in perl (yet).

Comment 10

[Dawn Endico]

The problem is that the header gets printed before data is read from
the bug so fixing this would require big changes.

Comment 11

[Jesse Ruderman]

I suggested a hack that would get around that...

Comment 12

[Matthew Tuck [:CodeMachine]]

Yes, but if bug_form.pl wasn't called in both places, you could move the header
into bug_form.pl.  So it's kind of a combination of the two.

It looks like the right thing to do is to try and read the data early and pass
it into bug_form.pl.  Is this possible?

Comment 13

[Chris Yeh]

possible, but not without some non-trivial amount of rewriting the information 
passing between form an .pl script.

Comment 14

[Stephan Niemz]

I made a fix for this really old bug, without any of the (more or less
dirty) hacks suggested above.

The change is only in show_bug.cgi, so process_bug.cgi is totally
unaffected. All I'm doing now is ask the database for the summary and then
display it (if there is a summary).

Okay, that's one more database query, and bug_form.pl fetches the summary
with all the other information later anyway, but from what I've seen there
are already other places where the DB is queried more than once for the
same information, and I think it's worth to live with this quick extra
query to get this often requested feature. (See the number of votes here.)

Nominating for 2.12. I have tested it on my local installation and it works
fine. Dave, could you please check this in?

Besides, the <title> is now "Bug 22041 - Bug page TITLE should include bug
summary" instead of "Bugzilla bug 22041", so I also left out the word
Bugzilla. I think we all know what bug system we're using, and as some
summaries tend to be quite long, I think it's better to have some extra
space for that in the window title or in the task bar.

Comment 15

[Stephan Niemz]

Attachment: proposed patch

Comment 16

[Dave Miller [:justdave]]

r=[e-mail]

Comment 17

[Dave Miller [:justdave]]

Painless fix.  Works as advertised.  No noticible performance loss.  checked in.

Comment 18

[Jacob Steenhagen]

*** Bug 68663 has been marked as a duplicate of this bug. ***

Comment 19

[Tara Hernandez]

Sorry for the spam, but I needed to be able to query for all of these correctly.

Comment 20

[Dawn Endico]

"show_bug.cgi" line 53

PutHeader("Bug $::FORM{'id'} - $summary", "Bugzilla Bug $::FORM{'id'}", $summary );

this line has a problem. The contents of $summary should first quote html
meta-characters.

I have a bug with a subject containing a select tag and a little dropdown
box is displayed instead of the subject.

Comment 21

[Jacob Steenhagen]

Attachment: bugfix - quote html in summary

Comment 22

[Jacob Steenhagen]

Dawn mentioned this was happening in show_bug.cgi and duplicates.cgi... so this
patch adds the line "$summary = html_quote($summary);" to both of them.

Comment 23

[Dawn Endico]

checked in jake's patch. marking fixed.

Comment 24

[Gervase Markham [:gerv]]

VERIFIED - this works.

Gerv

Comment 25

[Dave Miller [:justdave]]

Reopening...  this displays the summary of bugs you aren't allowed to see, even 
though it says "Permission denied" on the page.  For an example, if you don't 
have netscape-confidential privs, see bug 17494.

Comment 26

[Stephan Niemz]

Dave, that would be a new bug.  This bug is about "Bug page TITLE should
include bug summary", which is fixed now and works.

Marking fixed again.

Comment 27

[Dawn Endico]

no, it doesn't work because it shows the summary of bugs to people
who don't have the permission to see them. reopening

the secret summary is displayed both in the <TITLE> and in the
page header.

Comment 28

[Dawn Endico]

A quick fix for this would be to omit summary for bugs whose groupset is
anything but zero. that would let us release quickly without adding a
security hole and the real fix (checking the user's permissions) could be
implemented later if its too much of a pain to implement now.

Comment 29

[Jacob Steenhagen]

Bug 30694 patches both this and the tooltip security hole w/the quick fix we
talked about in IRC.  It essentially disables this feature for any bug that's
marked as confidential.

Comment 30

[Jacob Steenhagen]

Dawn checked in the "quick fix".  See bug 71767 for the proper fix.

Comment 31

[Matthew Tuck [:CodeMachine]]

Verified present on bugzilla.mozilla.org.

Comment 32

[Stephen Rasku]

Is this supposed to be fixed in 2.12?  I am not seeing this functionality in our
installation of 2.12.

Comment 33

[Jacob Steenhagen]

[e-mail]: See bug 71767

Comment 34

[Dave Miller [:justdave]]

Moving closed bugs to Bugzilla product

Comment 35

[Roland Mainz]

Which BugZilla version included this feature first ?

Comment 36

[Dave Miller [:justdave]]

Roland: 2.12.  (see the target milestone field - we set that to the current
milestone when the bug is resolved)

Comment 37

[Dave Miller [:justdave]]

*** Bug 199650 has been marked as a duplicate of this bug. ***