103523 - don't split buglist table every 100 bugs for new browsers

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Jesse Ruderman]

The bug list table should not be split every 200 bugs.  This causes several 
problems:

- It looks ugly to have the column widths change in the middle of what is 
conceptually one table.

- I can't select an entire column in order to generate statistics.  For 
example, I might want to select the reporter column of the unconfirmed list, 
and then use `sort', `uniq --count', and `sort -g' in order to get a list like
  5 [e-mail]
  7 [e-mail]
 71 [e-mail]
<http://www.gnu.org/manual/textutils/html_chapter/textutils_7.html>
(Note: I also run into bug 103522 when I try to do this.)

- I can't use the sort table bookmarklet effectively, so I have to ask the 
server to do the sort and wait for the results to be re-sent.
<http://www.squarefree.com/bookmarklets/pagedata.html#sort_table>

Comment 1

[Andreas Franke (gone)]

I think the current behaviour is for 4.x which is supposed to be very slow and
to use a lot of memory for tables with many rows.

Comment 2

[Matthew Tuck [:CodeMachine]]

Yes this is necessary for backward compatibility with non-reflowing browsers. 
It also causes the columns to reflow in a more sensible manner.

As for statistics, that's properly done over at bug #12282, which will hopefully
get some loving one of these days.

Comment 3

[Dave Miller [:justdave]]

For now we need this for backward compatibility.  Marking Future...  I hate it
too.  Once we succeed in getting people to stop using Nav 4 maybe we'll dump it.

Comment 4

[Adam Kennedy]

Why leave this hardcoded to 200...

If we were to use HTTP::BrowserDetect, you could an

# Pseudocode
sub HandlesLargeTables {
    return 1 if mozilla > 4;
    return 1 if ie > 4;
    return 1 if opera > xxx;
    etc etc
    return 0;    
}
And then only apply the 200 cell limit if the browser can't handle large tables.

I'd be happy to add the code if someone doesn't mind adding the installation
requirement of HTTP::BrowserDetect... or if we want to make sure it goes along,
we go always refactor the module into Bugzilla::BrowserDetect, and add it to CVS.

Say the word...

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

For a pure aesthetic purpose, a good workaround patch would just add a width
attribute to the TDs, or preferably a stylesheet...  Surely this wouldn't be
overly time consuming and might be worth getting in sometime soon (2.16?) just
for minimizing the annoyance factor.

Comment 6

[mental]

Updated summary to reflect changes made in bug 107379.

Comment 7

[Gervase Markham [:gerv]]

We could make this dependent on the user-agent without too much trouble; it
would be a tweak to the table.html.tmpl template.

Gerv

Comment 8

[Dave Miller [:justdave]]

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

Comment 9

[Frédéric Buclin]

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

Comment 10

[alanjstr]

Ok, it is now 2005 and there are 27 million copies of Firefox out there.  Can we
remove this split now?

Comment 11

[Gervase Markham [:gerv]]

Actually, today I think this is a WONTFIX. Having the column names repeated
every so often is helpful for a user, and those who want unadulterated results
for further processing can now use &format=csv.

Gerv

Comment 12

[Thomas F. O'Connell]

If this is WONTFIX, could it at least become a feature request to keep the columns aligned across the 
split?

Comment 13

[Jesse Ruderman]

Gerv, how is it useful to have the column names repeated every once in a while?

Comment 14

[alanjstr]

If you're on bug 300 of 1000 and can't remember which column is which ...
However I believe there are some attributes that can be set (see
http://juicystudio.com/experiments/accessibletables.asp )

One thing I do when using Excel is freeze the top row with the column headers so
that they never move while I'm scrolling.  This could be done by creating a
scrolling div to hold the whole table, but have an additional dummy row of
headers above the div.  The problem with that is table width to make the columns
line up.  But we can be creative with styles and have some default column widths
based on em.  

Comment 15

[Gervase Markham [:gerv]]

What alanjstr said.

Maybe we actually want something like this:
http://www.imaputz.com/cssStuff/bigFourVersion.html

Gerv

Comment 16

[alanjstr]

Fantastic find, gerv.  That's exactly what I was thinking of.

Comment 17

[Jesse Ruderman]

I don't understand alanjstr's argument.  What if you're on bug 350 of 1000?

Comment 18

[alanjstr]

(In reply to comment #17)
> I don't understand alanjstr's argument.  What if you're on bug 350 of 1000?

How would you remember which column was the assigneee and which was the qa and
which was the reporter?

Comment 19

[:glob ✱]

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

Comment 21

[Max Kanat-Alexander]

Attachment: v1

Easy-peasy.

Pyrzak's students' research pointed this out as an issue:

"There is no apparent reason as to why the heading information is repeated at this position in the page or why the columns are offset.  The user will not understand what is going on."

Comment 22

[Frédéric Buclin]

Comment on attachment 373429 [details] [diff] [review]
v1

>@@ -222,7 +219,7 @@
>   [%# At the end of every hundred bugs in the list, or at the end of the list,
>     # end the current table. 

Please fix the comment. "every hundred bugs" is no longer true.


>+  [% IF loop.last() %]
>     [% IF loop.last() && time_info.time_present == 1 %]

The 2nd loop.last() can go away.

Comment 23

[Max Kanat-Alexander]

Attachment: v2

Thanks for catching those things!

Comment 24

[Frédéric Buclin]

Comment on attachment 373451 [details] [diff] [review]
v2

r=LpSolit

Comment 25

[Max Kanat-Alexander]

Checking in template/en/default/list/table.html.tmpl;
/cvsroot/mozilla/webtools/bugzilla/template/en/default/list/table.html.tmpl,v  <--  table.html.tmpl
new revision: 1.43; previous revision: 1.42
done