03 Aug, 2007, Zeno wrote in the 1st comment:
Votes: 0
I thought I mentioned this, but it may have only been on IMC. Using Firefox, the white code box stops after a bit when viewing code. Thus you can't see more text, even though it's there.

Also, any chance we could make the viewer copy-friendly? When I copy, it also copies a # at the start of each line for some reason.
03 Aug, 2007, Guest wrote in the 2nd comment:
Votes: 0
Have you got an example of a code block that's broken in this manner? It might be the same thing I just fixed in the QSFP core code with the new skin but I need to be sure.

And the reason it's copying those # signs is because Firefox ( and IE ) are stupid when it comes to ordered lists that display line numbers. It thinks it needs to copy a placeholder for the digit space. The only way we could make that copy-friendly would be to remove the line numbers.
03 Aug, 2007, Zeno wrote in the 3rd comment:
Votes: 0
It has to be a long file. So like anything over 100k filesize should work.
03 Aug, 2007, Davion wrote in the 4th comment:
Votes: 0
Ya, what happens with the view (except when viewing archives) is it's formatted then inserted into the DB, then recalled on view. The size of the file, in addition to all the html added at format, might be larger than the text blob size for the db. I'll see about increasing it.
04 Aug, 2007, Zeno wrote in the 5th comment:
Votes: 0
Hm, if that was true then it wouldn't work on any browser would it? It works fine on IE.
04 Aug, 2007, Davion wrote in the 6th comment:
Votes: 0
Oh
04 Aug, 2007, Guest wrote in the 7th comment:
Votes: 0
http://www.mudbytes.net/index.php?a=file...

That's as good as an example as I could find after just waking up :P

The cause of this is a bug in the Firefox engine. It's something I've reported on before but I forget what the bugzilla number is for it now. It used to happen to a forum post with a sufficiently large code block as well.
04 Aug, 2007, Brinson wrote in the 8th comment:
Votes: 0
Yeah, its definitely a browser thing. Works fine in Opera.
04 Aug, 2007, Zeno wrote in the 9th comment:
Votes: 0
Samson said:
http://www.mudbytes.net/index.php?a=file...

That's as good as an example as I could find after just waking up :P

The cause of this is a bug in the Firefox engine. It's something I've reported on before but I forget what the bugzilla number is for it now. It used to happen to a forum post with a sufficiently large code block as well.


Can't you login and view all bugs that you've reported?
04 Aug, 2007, Guest wrote in the 10th comment:
Votes: 0
Yeah, but I was being lazy this morning. It was early, I'm entitled :)

Anyway, I've gone back and looked now and they've closed all of the bugs I've reported or voted on except one, which isn't related. So they apparently feel the issue was resolved. Guess I need to go report another and use that URL as proof.

New bug URL: https://bugzilla.mozilla.org/show_bug.cg...

If we want this fixed enough people need to help confirm it. Otherwise the developers there will ignore us as they often do.
10 Sep, 2007, Zeno wrote in the 11th comment:
Votes: 0
Quote
And the reason it's copying those # signs is because Firefox ( and IE ) are stupid when it comes to ordered lists that display line numbers. It thinks it needs to copy a placeholder for the digit space. The only way we could make that copy-friendly would be to remove the line numbers.

How about an option/link to display the code "Copy-friendly" (no line nums)?
03 Jul, 2008, Zeno wrote in the 12th comment:
Votes: 0
Haven't tested this in Fx3 yet. Any idea if this is fixed? Getting to be a real pain.
03 Jul, 2008, David Haley wrote in the 13th comment:
Votes: 0
When I copy/paste from a code box in Fx3, I get the line numbers, but no hash symbols.
03 Jul, 2008, Davion wrote in the 14th comment:
Votes: 0
Zeno said:
Haven't tested this in Fx3 yet. Any idea if this is fixed? Getting to be a real pain.


Pretty much the whole reason it isn't copy friendly is because it uses the ul/li tags. Doing it any other way (via table cells or what have you) make it nearly impossible for the line numbers to match the code. Trust me… we tried :S

Edit:

Cheap trick. If the pastebin is editable, you can simply go into the editor and c/p from the form.
04 Jul, 2008, Zeno wrote in the 15th comment:
Votes: 0
Er, didn't mean that. Was talking about Fx being unable to display the entire file.
04 Jul, 2008, David Haley wrote in the 16th comment:
Votes: 0
Why does using a table not work? If you used the same font in both, and aligned everything top/bottom the same way, wouldn't one row correspond to one line number / line content pair?
04 Jul, 2008, Kayle wrote in the 17th comment:
Votes: 0
Zeno: Just tested it with Fx3, and I still get the extra space where it should show more of the displayed file.
I used this file to test it, and my Fx3 displays it without error up until line 2029. then it all goes black a little into line 2030. So no, it doesn't appear to be fixed. =/
04 Jul, 2008, Zeno wrote in the 18th comment:
Votes: 0
Blarg.

Fx is not going to fix this. We need to find a workaround.
04 Jul, 2008, Davion wrote in the 19th comment:
Votes: 0
DavidHaley said:
Why does using a table not work? If you used the same font in both, and aligned everything top/bottom the same way, wouldn't one row correspond to one line number / line content pair?

You'd think that wouldn't you? Well, for some reason the vertical spacing changes and offsets the line numbers ever so slightly, and by the 100th line or so, you're 2-3lines off.
04 Jul, 2008, Davion wrote in the 20th comment:
Votes: 0
Zeno said:
Blarg.

Fx is not going to fix this. We need to find a workaround.


Got any suggestions?
0.0/32