Big patches not displayed properly in Firefox

[Ludvig Strigeus]

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

[Matthew Good <trac matt-good net>]

This is a Firefox/Win bug.

See ​http://lists.edgewall.com/archive/trac/2005-March/002379.html

[anonymous]

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.

[Mark Rowe]

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.

[Mark Rowe]

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.

[Matthew Good <trac matt-good net>]

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

[Christian Boos]

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

[Christopher Lenz]

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.

[Christian Boos]

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

[Christian Boos]

Just noticed that this is again broken…

[Christian Boos]

Here's a simple fix:

attachment.py

@@ -436 +436 @@
             else:
                 mimeview = Mimeview(self.env)
                 vdata = mimeview.render(req, mimetype, data,
-                                        attachment.filename)
+                                        attachment.filename, None,
+                                        annotations=['lineno'])
             req.hdf['attachment.preview'] = vdata
         finally:
             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()).

[Christian Boos]

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)

[Christian Boos]

Forgot to accept after assigning it to me…

[Christian Boos]

Applied the above patch​ in r2276