Bug - Fixed extra intraneous scrollbar
- Thread starter fredg1
- Start date
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...
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.
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.
through some fumbling'n'bumbling, I managed to add a whatif bar to a fight.php page.
Results were not conclusive.
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?
Results were not conclusive.
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?
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
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
View attachment overflow_page.zip
OK, here's the fight.php. I tried to lightly edit it in my text editor (to add a CR between tags), but I also included the original page. Hope these work for you!
OK, here's the fight.php. I tried to lightly edit it in my text editor (to add a CR between tags), but I also included the original page. Hope these work for you!
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.
This is the table and the same table with the inspector edited to change overflow:auto to overflow: visible
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.
This is the table and the same table with the inspector edited to change overflow:auto to overflow: visible
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)
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??
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)
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??
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!
(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..?
THAT'S why I never noticed that: this is indeed the same issue! Which happens only depends on the height of the page!
(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..?
So should I revert r20382?
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.
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:
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...
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?)
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?
I don't see any other table width = 95% in the page I captured, if you're looking for a different end condition.
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.