434701 - Possible visual artefacts in the last row of attachments table

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Alexey Gaidukov]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14
Build Identifier: 3.0.4

In last row of attachment table of show_bug.cgi page possible visual artects. It happends when text in the last row is too large.

Reproducible: Always

Steps to Reproduce:
1. Add an attachment for a bug
2. Delete attachmen or mark it as obsolete


In b.m.o. the problem is not reproducable because the table fairly wide. It is possible to reproduce in https://bugzilla.mozilla-russia.org.
Actual Results:  
The result you can see in attachment to the bug.


In the tamplet  default\attachment\list.html.tmpl not all the last row in the <span>.



  <tr class="bz_attach_footer">
    <td colspan="[% show_attachment_flags ? 3 : 2 %]">
      <span class="bz_attach_view_hide"> <!-- Should be here -->
      [% IF attachments.size %]
<!--        <span class="bz_attach_view_hide"> -->
          [% IF obsolete_attachments %]
            <a href="#a0" onClick="return toggle_display(this);">Hide Obsolete</a> ([% obsolete_attachments %]) |
          [% END %]
          <a href="attachment.cgi?bugid=[% bugid %]&amp;action=viewall">View All</a>
<!--        </span> -->
      [% END %]
      <a href="attachment.cgi?bugid=[% bugid %]&amp;action=enter">Add an attachment</a>
      (proposed patch, testcase, etc.)
     </span>  <!-- Should be here -->
    </td>
  </tr>

Comment 1

[Alexey Gaidukov]

Attachment: the visual artefact from bugzilla.mozilla-russia.org

Comment 2

[Frédéric Buclin]

Yeah, this is a known bug. I wonder why the attachment table isn't able to adapt itself so that there is no overlap. pyrzak, is it as simple as adding one line somewhere in a CSS file? This is really something which should be fixed for 3.2 (but I don't consider this problem as severe enough to be a blocker).

Comment 3

[Vitaly Fedrushkov]

This is not reproducible in 'en' locale, because english texts are shorter and fit to single line.

Test case (use different locales to look)

http://landfill.bugzilla.org/bugzilla30l10n/show_bug.cgi?id=6393

Comment 4

[Vitaly Fedrushkov]

Belorussian template uses explicit:

<span class="bz_attach_view_hide"><br><!--br - translation tag to fix bug-->

Comment 5

[Vitaly Fedrushkov]

Affected locales: de bg ru

Not affected: en fr pl

Cunning: be

Comment 6

[Marc Schumann [:Wurblzap]]

Does somebody recall why this last line is programmed seemingly backwards, with “float: right” CSS instead of simply putting the HTML a couple of lines further down?

Comment 7

[Frédéric Buclin]

The Bugzilla 3.0 branch is now locked to security bugs and dataloss fixes only. This bug doesn't fit into one of these two categories and is retargetted to 3.2 as part of a mass-change. To catch bugmails related to this mass-change, use lts081207 in your email client filter.

Comment 8

[Alexey Gaidukov]

Attachment: the artefact in 'en' locale

Comment 9

[Alexey Gaidukov]

(In reply to comment #3)
> This is not reproducible in 'en' locale, because english texts are shorter and
> fit to single line.
> 
> Test case (use different locales to look)
> 
> http://landfill.bugzilla.org/bugzilla30l10n/show_bug.cgi?id=6393

See https://bugzilla.mozilla.org/attachment.cgi?id=396405

Comment 10

[Vitaly Fedrushkov]

Target missed...

pyrzak: is comment 6 the right way or are there other CSS considerations here?

Comment 11

[Guy Pyrzak]

the reason for it being "backwards" is because if the "float:right" span is after the "add attachment" tag then the span will always appear below the "add attachment", which wasn't the intention for this UI (they're supposed to be on one line). 

I thought the fix would be to add a "clear" to the span, but that doesn't seem to work or fix it. Interestingly in safari this problem doesn't appear because the url in the attachment is on one line (just a side point). A possible fix is to add a <span> around the other text and float it left. That will make it appear on one line if there is enough horizontal space and then appear on 2 lines if there isn't. Then we should be able to play around with the ordering.

Comment 12

[Guy Pyrzak]

the other possible fix is add a min width to the table.

Comment 13

[Frédéric Buclin]

(In reply to comment #11)
> A possible fix is
> to add a <span> around the other text and float it left. That will make it
> appear on one line if there is enough horizontal space and then appear on 2
> lines if there isn't.

We shouldn't let them be on two lines. In that case, make the attachment table wider.

Comment 14

[Marc Schumann [:Wurblzap]]

How about a nested table? This would allow the outer table to size itself properly automatically, and we wouldn't need the hack of tweaking the width.

Comment 15

[Frédéric Buclin]

IMO, still using tables to achieve this in 2009 is pretty ugly.

Comment 16

[Frédéric Buclin]

Bugzilla 3.2 is restricted to security bugs only. Moreover, this bug is either assigned to nobody or got no traction for several months now. Rather than retargetting it at each new release, I'm clearing the target milestone and the bug will be retargetted to some sensible release when someone starts fixing this bug for real (Bugzilla 3.8 more likely).

Comment 17

[Vitaly Fedrushkov]

(In reply to comment #12)
> the other possible fix is add a min width to the table.

done at bug 537083, localizers are invited to test.

Comment 18

[Frédéric Buclin]

(In reply to comment #17)
> done at bug 537083, localizers are invited to test.

I *think* bug 537083 will fix this problem too, so setting [blocker will fix] for now.

Comment 19

[Frédéric Buclin]

I just tested, and yes, bug 537083 fixes this problem.