Edgewall Software
Modify

Opened 19 years ago

Closed 19 years ago

Last modified 18 years ago

#1345 closed defect (fixed)

Big patches not displayed properly in Firefox

Reported by: Ludvig Strigeus Owned by: Christian Boos
Priority: normal Milestone: 0.9
Component: general Version: 0.8.1
Severity: normal Keywords: code css
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Go to: http://projects.edgewall.com/trac/attachment/wiki/NewWorkflow/patch-newworkflow-r1102.diff

Scroll down to the middle of the file or more, I don't know if it's a firefox bug or Trac bug, but the display looks all messed up if you scroll down to more than 50% of the patch. The screen stops redrawing.

On Windows XP with Firefox 1.0.1

Attachments (1)

1345-fix.patch (6.0 KB ) - added by Christian Boos 19 years ago.
Updated patch. Fixes this issue by using a common code for both the browser view and the attachment view (now also tested with binary files, both below and above the max preview size)

Download all attachments as: .zip

Change History (14)

comment:1 by Matthew Good <trac matt-good net>, 19 years ago

Resolution: invalid
Status: newclosed

comment:2 by anonymous, 19 years ago

Resolution: invalid
Status: closedreopened

Since this is a Firefox bug, Trac should provide a workaround until the bugs with Firefox are fixed.

In my opinion, Trac shouldn't rely on features that are supported in the standards, but are not properly implemented. Compare with C++ templates.

comment:3 by Mark Rowe, 19 years ago

Resolution: fixed
Status: reopenedclosed

I hardly think that displaying a large HTML page is a "feature" of a browser. Please file a bug against the relevant version of Firefox at bugzilla.mozilla.org. I tested this using Firefox 1.0.2 on Mac OS X and did not experience the described problem, so it is possible that it is a Windows-only issue.

comment:4 by Mark Rowe, 19 years ago

Resolution: fixedinvalid

I hardly think that displaying a large HTML page is a "feature" of a browser. Please file a bug against the relevant version of Firefox at bugzilla.mozilla.org. I tested this using Firefox 1.0.2 on Mac OS X and did not experience the described problem, so it is possible that it is a Windows-only issue.

comment:5 by Matthew Good <trac matt-good net>, 19 years ago

Yes, this is a Windows-only issue. Firefox on Linux does not have this problem either.

comment:6 by Christopher Lenz, 19 years ago

Milestone: 0.8.2

comment:7 by Christian Boos, 19 years ago

Priority: highnormal
Resolution: invalid
Status: closedreopened

The problem described in this ticket disappears when you remove the overflow: auto from the .code-block CSS specification (in source:trunk/htdocs/css/code.css)

overflow: scroll also triggers the bug and either removing the overflow value or explicitely setting it to overflow: visible fixes it.

Note that IE on Windows also benefits from that change: even if it works with overflow: auto , it's much slower than without…

It would be worth checking the performance difference between the two settings on the platforms where it was reported to work (Linux, MacOS, …)

In summary:

overflow: auto is indeed nice for small code blocks, but it's a real problem (at least on Windows) for big code blocks both with Firefox (the rendering bug) and with IE (the slowness), for no real gain since having scrollbars is problematic anyway (see #1397).

Therefore I'd propose removing the .code-block { overflow: auto } setting and create a .small-code-block { overflow: auto } CSS class which will be set on small code fragments (e.g. no more than 10 lines).

comment:8 by Christopher Lenz, 19 years ago

Keywords: layout added
Milestone: 0.9
Owner: changed from Jonas Borgström to Christopher Lenz
Priority: normallow
Severity: majorminor
Status: reopenednew

So let's just drop the overflow property on attachments and repository files, but keep it for code blocks embedded in wiki pages (which should pretty much always be rather short). I'll take this one.

comment:9 by Christian Boos, 19 years ago

Resolution: fixed
Status: newclosed

The fix for #520 in [1764] also fixes this ticket.

comment:10 by Christian Boos, 19 years ago

Keywords: code css added; layout removed
Milestone: 0.9
Priority: lowhigh
Resolution: fixed
Severity: minornormal
Status: closedreopened

Just noticed that this is again broken…

comment:11 by Christian Boos, 19 years ago

Milestone: 0.9
Owner: changed from Christopher Lenz to Christian Boos
Priority: highnormal
Status: reopenednew

Here's a simple fix:

  • attachment.py

     
    436436            else:
    437437                mimeview = Mimeview(self.env)
    438438                vdata = mimeview.render(req, mimetype, data,
    439                                         attachment.filename)
     439                                        attachment.filename, None,
     440                                        annotations=['lineno'])
    440441            req.hdf['attachment.preview'] = vdata
    441442        finally:
    442443            fd.close()

However, a better fix would be to refactor the similar code in attachment.py and browser.py into a single method (e.g. Mimeview.preview_to_hdf()).

by Christian Boos, 19 years ago

Attachment: 1345-fix.patch added

Updated patch. Fixes this issue by using a common code for both the browser view and the attachment view (now also tested with binary files, both below and above the max preview size)

comment:12 by Christian Boos, 19 years ago

Status: newassigned

Forgot to accept after assigning it to me…

comment:13 by Christian Boos, 19 years ago

Resolution: fixed
Status: assignedclosed

Applied the above patch in r2276

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.