Bug - Fixed extra intraneous scrollbar

fredg1

Member
also the issue with display:none is that if the apparition of the table suddenly creates an overflow, then a scroll bar is suddenly added. This scroll bar then "pushes" everything a little bit to the left, which, given the size of the links on which you need to hover to make the table appear, can be enough to make it so that the link is pushed away from under your mouse...
 

MCroft

Developer
Staff member
yeah, display: none and visibility:hidden are for different things.

visibility: hidden is an invisible box that affects the layout and doesn't display anything. Very useful if you're wanting things to disappear and reappear without re-laying out the page. The way I see it done if you don't want the overflow problem you describe is display:none; overflow: hidden. But if we could anchor the visibility hidden section elsewhere, it might not have the effect. It's auto-sizing the containing box which is causing the issue I'm seeing.
 

fredg1

Member
I'd still need more info about this event.

Try to get this to happen again, and when it does, right-click > Save Page As..., then send the result here (it should make both a .htm file and a folder; send both)
 

fredg1

Member
through some fumbling'n'bumbling, I managed to add a whatif bar to a fight.php page.
Results were not conclusive.
LdbyUCYfwm.pnguVGV6HISrl.png

Even setting a negative z-index to the table, it still wasn't cropped in any way.
This means I'd really need the actual HTML from an instance of this happening.

It doesn't help that I'm still not sure if the CAB is involved in this. If I understand correctly, you start the fight with the CAB, then turn on the old combat form?
 

MCroft

Developer
Staff member
I captured the generated html and ran it through htmlTidy so I could read it. That's attached here: View attachment Fightpage.zip

Hope either that or this description below helps.

Here's what I see in fight.php:There's a div with the id content_. That's where the content appears (well named!). It contains a div with the id "effdiv" which is empty and has the display:none property set. No idea why, but it does make it easy to find what I'm seeing. On next line (201), there's a div inside the content_ div with the property overflow:auto. All the content of content_ is in this inner overflow:auto div.

That's related to the issue. Since the div is overflow:auto and that contains the whatif table, when it overflows the box for the div, it results in a scroll bar. I see it sometimes because the whatif table overflows the div sometimes. Since I'm on Safari, the scrollbar is hidden unless I hover near it.

In the cases I've seen, the div is the last item with content on the page, since there's nothing but script tags after it, so I'm not sure what overflow: hidden does for this div. Maybe there are other things that can be enabled to put something at the bottom that this helps with. Or maybe it has something it does in other parts of a fight.

With overflow: auto on the div and with overflow: visible
Screen Shot 2020-09-25 at 12.51.13 AM.pngScreen Shot 2020-09-25 at 12.50.40 AM.png
 

fredg1

Member
"effdiv" actually seems to be what contains the "results" sectionTxUyEKy4Nh.png
(I say "seems" only because I don't know if more than just "results" go there)

Just like fightform, it's just set to display:none normally
 

fredg1

Member
I'd need the true, actual, raw HTML; htmlTidy seems to have messed up some of the formatting :|

4DgTTVCwBj.png
 
Last edited:

MCroft

Developer
Staff member
So this is what I think the problem is. The size of the div containing the results is large enough for the contents, but the whatif table can be overflow, since it's placed relative to the command after the new inventory item.

When it does go longer than the containing box it gets cut off, which is exactly what you'd expect for the div having the property overflow:auto but unfortunate if you want to see all those rows in your long item.

This is the div highlighted and in the inspector.
div_with_style_that_cuts_off_WhatIf_Table.png InspectorOnDivInQuestion.png

This is the table and the same table with the inspector edited to change overflow:auto to overflow: visible
WhatIfTable_Being_Cut_Off.pngWhatIfTable_is_visible_if_overflow_visible_on_enclosing_div.png
 

fredg1

Member
Wait... that's it??

That's literally the bug that this thread was about the whole time! (or, more exactly, the same source; I don't know why, but instead of creating an extra scrollbar to scroll to the content, this one is being hidden instead)

You should have pointed out how it created a scroll bar that doesn't span the whole height of the page, and it would have been obvious! (did you? maybe you did but it went over my head)
AqfkZddqV1.png

For both, overflow:visible solves the issue.


...wait, on the very first thing you posted, weren't you actually using the patch that did that??
 

fredg1

Member
THAT'S it!!

THAT'S why I never noticed that: this is indeed the same issue! Which happens only depends on the height of the page!

nUCExNfKLk.png

(And I was never slowed down by it if the page was fitting in the screen, since I could reach the "adventure again" button without scrolling, and I never use these tables)



... still need to know how you managed to get that issue after applying the patch, though..?
 

MCroft

Developer
Staff member
I think it probably partially works, just not in my case. It's not that the patch is wrong, it just doesn't apply in my related case.

Apologies if it wasn't clear. My understanding has evolved as I looked at this over the last few days.

When I look at the diff of 20381>20382, it looks like it should set the div to overflow:visible, but isn't getting called in all cases. In my case, I'm not seeing a faaaaaaart comment in the source, so the index will be -1 and the code isn't changing the div.


Code:
// Modify the 'overflow' div, after the 'content_' div, to prevent the appearance of an inner scroll bar due to use link decorations
int content_Index = buffer.indexOf( "id='content_'" );
int overflowIndex = buffer.indexOf( "<div style='overflow: auto'><center><!--faaaaaaart-->", content_Index );
if ( overflowIndex != -1 )
{
	// Replace 'auto' into 'visible'
	overflowIndex += 22;
	buffer.replace( overflowIndex, overflowIndex + 4, "visible" );
}
 
Last edited:

fredg1

Member
I think it probably partially works, just not in my case. It's not that the patch is wrong, it just doesn't apply in my related case.

Apologies if it wasn't clear. My understanding has evolved as I looked at this over the last few days.

When I look at the diff of 20381>20382, it looks like it should set the div to overflow:visible, but isn't getting called in all cases. In my case, I'm not seeing a faaaaaaart comment in the source, so the index will be -1 and the code isn't changing the div.


Code:
// Modify the 'overflow' div, after the 'content_' div, to prevent the appearance of an inner scroll bar due to use link decorations
int content_Index = buffer.indexOf( "id='content_'" );
int overflowIndex = buffer.indexOf( "<div style='overflow: auto'><center><!--faaaaaaart-->", content_Index );
if ( overflowIndex != -1 )
{
	// Replace 'auto' into 'visible'
	overflowIndex += 22;
	buffer.replace( overflowIndex, overflowIndex + 4, "visible" );
}

I see! That's interesting...
This means I shouldn't include the "<!--faaaaaaart-->" in the search. However, "<div style='overflow: auto'><center>" is still pretty vague, could be at another spot in the code, so I'll try to limit the search to between "id='content_'" and "id="monsterpic"", if they are present.
...what should I do if monsterpic is not present, though? I know for a fact that currently, using Army of Toddlers causes a glitch (KoL glitch, not mafia) that causes the monster's table to not display...

So should I revert r20382?

don't revert r20382, but add this patch! View attachment StationaryButtonDecorator.java.patch

(it includes the change to the use link decorations' z-index in UseLinkDecorator.java, since it was still not added when previously submitted. Forgotten, or put on hold while waiting for development?)
 

MCroft

Developer
Staff member
I will test tonight after rollover.

I think it would be a big pain to parse open and close div tags to find where the end of the div is.

Is this always present?
HTML:
<div style='overflow: auto'>
<center>
<table  width=95%

I don't see any other table width = 95% in the page I captured, if you're looking for a different end condition.
 

MCroft

Developer
Staff member
I'll look tonight, to see if I see it at all. But are "with and without fart comment" the only two options? If so, you could do a longer match with ||.

Or maybe a regex.
 
Top