Pages:
Author

Topic: Post history (action=profile;sa=showPosts) sometimes renders [code] too wide - page 2. (Read 799 times)

hero member
Activity: 510
Merit: 4005
I often check someone's post history, and this has always been annoying. It makes me maximize my browser and scroll horizontally. It must be even more annoying for campaign managers who manually check users' posts.
Yup, that's part of the reason I set time aside for this, I'm looking to apply soon (probably to the ChipMixer campaign, if slots ever open up) and I don't want my post history to look like a mess, when I do.

I'm not sure what the delay is, but I'm guessing theymos has a good reason. I diff my patches (out of necessity) against SMF 1.1.19, so I imagine that it takes some effort on theymos' side to work around the differences between stock SMF and his heavily-modified version. I'm planning on submitting a 2FA patch soon, and that one will probably take substantial effort to massage into place.
copper member
Activity: 1526
Merit: 2890
Bumping! I just checked OP's last topic history to see if this was fixed (after all, theymos Merited this topic), but it isn't.
I often check someone's post history, and this has always been annoying. It makes me maximize my browser and scroll horizontally. It must be even more annoying for campaign managers who manually check users' posts.

You bet! I have been checking this almost everyday at least once to check if the patch solution is applied or the css solution.

Even to double check I will open it in incognito mode to see if the cache is preventing CSS updates.

In my example post which I linked above from my show post history is not valid any more because that time it was on page 26 and now its on Page 31

Since I'm here I will slightly update the above code with css parameter important to make sure it is not conflicting with existing code cssclass.


Code:
pre, .code{
white-space: pre-wrap !important;
}
legendary
Activity: 3290
Merit: 16489
Thick-Skinned Gang Leader and Golden Feather 2021
Bumping! I just checked OP's last topic history to see if this was fixed (after all, theymos Merited this topic), but it isn't.
I often check someone's post history, and this has always been annoying. It makes me maximize my browser and scroll horizontally. It must be even more annoying for campaign managers who manually check users' posts.
hero member
Activity: 510
Merit: 4005
I see what's the problem... actually in chrome based browsers (Chrome and Edge)
 tag is not present. The code appears directly in the div.
Nice catch! I'm always on Tor, so I've never seen the forum's HTML on other browsers.

I'll tweak the patch to account for this, and update the topic when I'm done. Smiley

Edit: Okay, all done.

The approach that this patch takes may seem a little complicated to some (when compared to simply changing the CSS forum-wide to use white-space: pre-wrap; on the relevant elements), but I think the extra complexity is justified. I considered, tested, and then abandoned that (much) easier approach early on, because although it works (superficially), I don't like the line breaks that it inserts into code (I'd prefer to stick to the established way of presenting "wide" code on Bitcointalk, with scroll bars instead of text wrapping).
copper member
Activity: 1526
Merit: 2890
Yep. That's the first thing I tried, too (on the
 element though, not the 
; I'm surprised doing that on the
had any effect for you).

I see what's the problem... actually in chrome based browsers (Chrome and Edge)
 tag is not present. The code appears directly in the div.



So this solution should work in Chrome and Edge white-space: normal; or white-space: pre-wrap;

But for firefox there's is
 tag that's why parent div is not getting effected, in this case additional css should solve the issue.

Adding below CSS anywhere in the style page should solve the issue for both Chrome and Firefox.

Code:
pre, .code{
white-space: pre-wrap !important;
}



I agree with your first solution of patching the profile template. Here I'm just giving an alternate solution for theymos to choose.


Edited
legendary
Activity: 1568
Merit: 6660
bitcoincleanup.com / bitmixlist.org
Yes please! I hit this wall way too often especially with long code snippets. I previously messed around with the CSS trying to figure out the problem but all I managed to do was break the layout.
hero member
Activity: 510
Merit: 4005
But i guess below small update in css should fix the issue

https://bitcointalk.org/Themes/custom1/style.css

Line: 151: white-space: nowrap;   ==>  white-space: normal;
Yep. That's the first thing I tried, too (on the
 element though, not the 
; I'm surprised doing that on the
had any effect for you). The problem with that approach (i.e. just adding white-space: normal; to the CSS) is that it collapses whitespace (in a browser-dependent way), which is obviously not ideal for preformatted stuff (like source code). white-space: pre-wrap; is a little better, but that still introduces line breaks, which I'm not convinced won't end up sometimes affecting copy/paste on particular configurations/systems.

So, the approach I took was to leave the default white-space: nowrap; on
 elements alone (so that content is presented exactly as authored) but still find a way to size them as if white-space: pre-wrap; was being used (see the patch for details).            
legendary
Activity: 2758
Merit: 6830
But i guess below small update in css should fix the issue

https://bitcointalk.org/Themes/custom1/style.css

Line: 151: white-space: nowrap;   ==>  white-space: normal;
That worked! I'm using it through the Stylus browser extension.

Hopefully this is fixed forum-wide, though. I remember actually trimming my code a few times so that page doesn't break.
legendary
Activity: 2212
Merit: 7064
Anyone else notice that if you wrap something that contains really long lines with [code] tags, that it'll look okay in the actual post, but if you browse your post history afterwards, it'll render much wider than the surrounding posts and throw everything out?
It happened to me several times before and I never understood the reason why this is happening.
People who are mostly affected with this glitch are probably members who are creating many ANN topics and adding codes for signature and stuff like that.

@theymos: Please consider merging this fix, or applying your mind to the problem and coming up with something better. Thanks!
Majority of people will never notice this but I still think it would be a good idea to apply this fix, so nice work again PowerGlove.
copper member
Activity: 1526
Merit: 2890
Anyone else notice that if you wrap something that contains really long lines with [code] tags, that it'll look okay in the actual post, but if you browse your post history afterwards, it'll render much wider than the surrounding posts and throw everything out?

Yes that's true here another example and see how wide is the page Smiley

But i guess below small update in css should fix the issue

https://bitcointalk.org/Themes/custom1/style.css

Line: 151: white-space: nowrap;   ==>  white-space: normal;

Code:
.code
{
color: #000000;
background-color: #fff;
font-family: "courier new", "times new roman", monospace;
font-size: 12px;
line-height: 1.3em;
/* Put a nice border around it. */
border: 1px solid #000000;
padding: 5px;
margin: 1px 3px 4px 6px;
width: 93%;
/* Don't wrap its contents, and show scrollbars. */
white-space: nowrap;   <------------------------------------- white-space: normal;
overflow: auto;
/* Stop after about 24 lines, and just show a scrollbar. */
max-height: 24em;
}
legendary
Activity: 3668
Merit: 6382
Looking for campaign manager? Contact icopress!
Anyone else notice that if you wrap something that contains really long lines with [code] tags, that it'll look okay in the actual post, but if you browse your post history afterwards, it'll render much wider than the surrounding posts and throw everything out?

Although it doesn't happen to me too often, I know very well what you're talking about!
And I hoped that someday it'll get fixed.

I messed around for a few (very frustrating) hours trying to get to the bottom of this, and managed to come up with the following SMF patch:

Thank you!
I am sure that this will be added. It's, after all, a bugfix (and, no offense, but I find this more useful than the "OP" patch).
hero member
Activity: 510
Merit: 4005
Anyone else notice that if you wrap something that contains really long lines with [code] tags, that it'll look okay in the actual post, but if you browse your post history afterwards, it'll render much wider than the surrounding posts and throw everything out?

Here's an example of what I mean: I recently posted some code that contained a few really long lines, here. If you look at that post, it renders without issue (i.e. that post doesn't render wider than the other posts in that thread). But, if you look (currently) at the first page of my post history, you'll see that the posts on that page are rendering strangely, making them difficult to read without lots of horizontal scrolling.

I messed around for a few (very frustrating) hours trying to get to the bottom of this, and managed to come up with the following SMF patch:

Code:
--- /var/www/baseline/Themes/default/Profile.template.php	2007-02-03 15:55:14.000000000 +0000
+++ /var/www/modified/Themes/default/Profile.template.php 2023-01-06 00:15:50.000000000 +0000
@@ -341,42 +341,45 @@
  if (!empty($context['posts']))
  {
  // Page numbers.
  echo '
 
 
  ', $txt[139], ': ', $context['page_index'], '
 
 
  ';
 
  // Button shortcuts
  $quote_button = create_button('quote.gif', 145, 'smf240', 'align="middle"');
  $reply_button = create_button('reply_sm.gif', 146, 146, 'align="middle"');
  $remove_button = create_button('delete.gif', 121, 31, 'align="middle"');
  $notify_button = create_button('notify_sm.gif', 131, 125, 'align="middle"');
 
  // For every post to be displayed, give it its own subtable, and show the important details of the post.
  foreach ($context['posts'] as $post)
  {
+ // style="table-layout: fixed;" was added to each subtable as a partial fix for code sometimes rendering too wide (see https://bitcointalk.org/index.php?topic=5432954).
+ // This could also have been done further up the hierarchy, but this is a more natural place to apply the fix, and (surprisingly) produces slightly superior results, too.
+ // There's a second (progressive enhancement) part to this fix, after this foreach.
  echo '
-
+

 
 
 
 

 
 
 
 
 
 
 
 
 
 
@@ -391,40 +394,67 @@
  if ($post['can_reply'])
  echo '
  ', $reply_button, '', $context['menu_separator'], '
  ', $quote_button, '';
  if ($post['can_reply'] && $post['can_mark_notify'])
  echo '
  ', $context['menu_separator'];
  if ($post['can_mark_notify'])
  echo '
  ' . $notify_button . '';
 
  echo '
 
 
 

  ', $post['counter'], '
 

   ', $post['category']['name'], ' / ', $post['board']['name'], ' / ', $post['subject'], '
 

  ', $txt[30], ': ', $post['time'], '
 

 
', $post['body'], '

 

 
';
  }
 
+ // This is the second part of the fix for code sometimes rendering too wide (the first part is at the top of the preceding foreach).
+ // The first part only prevents the problem from affecting surrounding posts, but when JavaScript is available, a more complete fix can be made.
+ // This code visits each eligible element and (defensively) sets the width to the same computed value.
+ // The width is computed once and then reused, not because of performance considerations (that's a nice consequence), but because that approach fixed some (rare) problem cases that came up in testing.
+ // The initial version of this code didn't account for the presence of
 elements being browser-dependent (that's what the "target" variable now does).
+ echo '
+ ';
+
  // Show more page numbers.
  echo '
 
 
 
 
 

  ', $txt[139], ': ', $context['page_index'], '
 
';
  }
  // No posts? Just end the table with a informative message.
  else
  echo '
 
 
  ', $txt[170], '
 
 
  ';
 }

Edit: Updated to account for browser differences pointed out by shahzadafzal.

@theymos: Please consider merging this fix, or applying your mind to the problem and coming up with something better. Thanks!



So, I ended up sinking more time into this problem and coming up with a (much) better patch... Smiley

(Thanks to PX-Z for the script they left here, those particular DOM modifications weren't the ones I ended up using, but, the final fix I arrived at was definitely influenced by that post.)

Code:
--- baseline/Themes/default/Profile.template.php	2007-02-03 15:55:14.000000000 +0000
+++ modified/Themes/default/Profile.template.php 2024-04-27 20:51:35.000000000 +0000
@@ -346,43 +346,48 @@
 
  ', $txt[139], ': ', $context['page_index'], '
 
 
  ';
 
  // Button shortcuts
  $quote_button = create_button('quote.gif', 145, 'smf240', 'align="middle"');
  $reply_button = create_button('reply_sm.gif', 146, 146, 'align="middle"');
  $remove_button = create_button('delete.gif', 121, 31, 'align="middle"');
  $notify_button = create_button('notify_sm.gif', 131, 125, 'align="middle"');
 
+ // Controls whether or not an effort is made to prevent "wide" content from breaking the layout (e.g. code blocks containing really long lines).
+ $with_wide_fix = true;
+
  // For every post to be displayed, give it its own subtable, and show the important details of the post.
  foreach ($context['posts'] as $post)
  {
  echo '
 
 
 

 
 
 
 
 
-
+ ', $with_wide_fix ? '
+

  ', $post['counter'], '
 

   ', $post['category']['name'], ' / ', $post['board']['name'], ' / ', $post['subject'], '
 

  ', $txt[30], ': ', $post['time'], '
 

+ ' : '', '
 
 
 
 
 
 
 
 

 
', $post['body'], '

 
';
 
  if ($post['can_delete'])
  echo '
  ', $remove_button, '';
  if ($post['can_delete'] && ($post['can_mark_notify'] || $post['can_reply']))

I also came up with a patch that fixes this problem when previewing PMs and when replying to PMs:

Code:
--- baseline/Themes/default/PersonalMessage.template.php	2006-12-01 15:43:03.000000000 +0000
+++ modified/Themes/default/PersonalMessage.template.php 2024-04-27 20:51:50.000000000 +0000
@@ -855,29 +855,32 @@
 
';
  foreach ($context['send_log']['sent'] as $log_entry)
  echo '', $log_entry, '
';
  foreach ($context['send_log']['failed'] as $log_entry)
  echo '', $log_entry, '
';
  echo '
 

';
  }
 
+ // Controls whether or not an effort is made to prevent "wide" content from breaking the layout (e.g. code blocks containing really long lines).
+ $with_wide_fix = true;
+
  // Show the preview of the personal message.
  if (isset($context['preview_message']))
  echo '
 

-
+

 
 
 
 
 
 
 
', $context['preview_subject'], '

  ', $context['preview_message'], '
 

';
 
  // Main message editing box.
  echo '
@@ -985,30 +988,30 @@
 
';
 
  // Some hidden information is needed in order to make the spell checking work.
  if ($context['show_spellchecking'])
  echo '
 
';
 
  // Show the message you're replying to.
  if ($context['reply'])
  echo '
 

 

-
+

 
 
 
 
-
 
 
 
 
 
', $txt[319], ': ', $context['quoted_message']['subject'], '

+

 
 
 
 
 
 
', $txt[318], ': ', $context['quoted_message']['member']['name'], '', $txt[30], ': ', $context['quoted_message']['time'], '

 
', $context['quoted_message']['body'], '
';
Pages:
Jump to:
© 2020, Bitcointalksearch.org