I checked in the patch, unmodified. If there is a problem let's sort it out and fredg1 can fix or I can revert until it is fixed.
Bug - Fixed extra intraneous scrollbar
- Thread starter fredg1
- Start date
For your first issue, the problem is that I don't see/never saw it.
You said it "still cuts off the last bit"? You mean it was a thing that happened before this patch?
For the second "issue", it should simply be a matter of raising the z-index of the speculation table. I already noticed times where other elements were "competing" for visibility with that table (in your first screenshot, for example, we can see the [use] link of the knob goblin firecracker in the middle of the table)
This is, however, the first time that I see a KoL image being ON TOP of the speculation (most likely because it was never reaching them before). This would mean that those images probably already have a z-index. I'd need to check the image itself to find more about it, but I currently don't have access to the palindome... (community service)
Ok, I managed to reproduce the Palindome (thanks The Dictator for the HTML).
Turns out the Palindome doesn't have a z-index. Instead, this (the palindome being in front) is caused by their container being Position:relative, which is necessary for the other images to stick to the group:
The situation is solved by giving the pop-up a z-index of as little as 1:
Here's the patch that does that: View attachment UseLinkDecorator.java.patch
Tested
Turns out the Palindome doesn't have a z-index. Instead, this (the palindome being in front) is caused by their container being Position:relative, which is necessary for the other images to stick to the group:
The situation is solved by giving the pop-up a z-index of as little as 1:
Here's the patch that does that: View attachment UseLinkDecorator.java.patch
Tested
Last edited:
I downloaded 20381 from the jenkins server, so it's before the patch was applied.
This is easy to recreate with something like a very busy 2CRS ring of stuff...
Here you can see that the table is cut off at the bottom.
If you scroll the window, then more of the table smoothly becomes visible
Here you can see the inspector of the HTML that's getting cut off. It's hard to show this without being slightly misleading. It looks like content_ is full size but that the overflow:auto div is the one that is short. Somehow.
This is easy to recreate with something like a very busy 2CRS ring of stuff...
Code:
Michaels-MBP:Downloads mcroft$ java -jar KoLmafia-20381.jar
KoLmafia v20.7 r20381
Released on July 30, 2020
Currently Running on Mac OS X
Local Directory is /Users/mcroft/Library/Application Support/KoLmafia
Using Java 13.0.2If you scroll the window, then more of the table smoothly becomes visible
Here you can see the inspector of the HTML that's getting cut off. It's hard to show this without being slightly misleading. It looks like content_ is full size but that the overflow:auto div is the one that is short. Somehow.
Attachments
Ok, so, I don't know if you can also do this in Safari, but in Firefox, if you hover over an element in the Element Inspector, it's highlighted it blue in its entirety, even if it's visibility is hindered by something else (such as having reached the limit of the overflow zone):
(as you may notice, the section is cut because I reverted the overflow of the section to "auto", undoing the patch I first submitted here)
First, if you hover over the table itself in the inspector, is the highlighted part really bigger than the visible one? If not, it's surely an issue with Safari...
Second, if you hover over every container above the table itself (just slowly move your mouse over all of them), does one of them just so happen to have an edge that corresponds to where the table gets cut?
(as you may notice, the section is cut because I reverted the overflow of the section to "auto", undoing the patch I first submitted here)
First, if you hover over the table itself in the inspector, is the highlighted part really bigger than the visible one? If not, it's surely an issue with Safari...
Second, if you hover over every container above the table itself (just slowly move your mouse over all of them), does one of them just so happen to have an edge that corresponds to where the table gets cut?
This interests me. As an observer, rather than a participant.
In my last job, before I retired earlier this year, CSS and Javascript was a technology I encountered on the job - and it was always opaque, even though I'd been employed as a programmer for more than 45 years prior.
Now that I am retired and doing KoLmafia as a hobby, I see the issues, have no skill in the debugging tools needed to investigate issues like this, and will wait for others with skills I don't want to learn to debug and propose patches for issues in CSS and Javascript.
Go you!
In my last job, before I retired earlier this year, CSS and Javascript was a technology I encountered on the job - and it was always opaque, even though I'd been employed as a programmer for more than 45 years prior.
Now that I am retired and doing KoLmafia as a hobby, I see the issues, have no skill in the debugging tools needed to investigate issues like this, and will wait for others with skills I don't want to learn to debug and propose patches for issues in CSS and Javascript.
Go you!
Javascript is the only language I've actually had classes in, since high school. Grad school assumed I knew Java and I had to fake it. It shows. 
But what I see when I use the inspector to find the long element is that it's getting cut off by the div fightform.hideform
It seems to be an interaction between position: relative (the whatif table) and position:absolute (the fightform element).
This image shows the box model as computed, and you can get this by hovering over the {}* in the styles pane of the inspector. It's really useful.
These images are the fight form source and CSS
These images are the whatif table source and CSS
But what I see when I use the inspector to find the long element is that it's getting cut off by the div fightform.hideform
It seems to be an interaction between position: relative (the whatif table) and position:absolute (the fightform element).
This image shows the box model as computed, and you can get this by hovering over the {}* in the styles pane of the inspector. It's really useful.
These images are the fight form source and CSS
These images are the whatif table source and CSS
fight form is "old combat form" and is always on the page. sometime visible, sometimes not.
1:so, looking at a fight with CAB turned on that does not return an object.
a: Initially, div fightform is there, but is not visible. (class hideform).
b: When I press "show old combat form", fightform becomes visible and I can use it to fight.
c: after I win (and don't get an equipable item), fightform switches to visibility hidden again.
2: same thing if I use buttons at the top, except for no step b.
That seems normal...
I'm coming to the conclusion that this is intermittent based on the number of lines (and thus the box size) of different combats and changed properties. With some combination, the hidden fightform pushes down, expands the outer div, and the non-expanding inner div (that the table is inside) doesn't grow, so the table is cut off because it's longer than it's container, but not it's container's container.
I will try to make that messy-sounding paragraph into some demonstration HTML or better yet a solution. Not sure how that will go...
1:so, looking at a fight with CAB turned on that does not return an object.
a: Initially, div fightform is there, but is not visible. (class hideform).
b: When I press "show old combat form", fightform becomes visible and I can use it to fight.
c: after I win (and don't get an equipable item), fightform switches to visibility hidden again.
2: same thing if I use buttons at the top, except for no step b.
That seems normal...
I'm coming to the conclusion that this is intermittent based on the number of lines (and thus the box size) of different combats and changed properties. With some combination, the hidden fightform pushes down, expands the outer div, and the non-expanding inner div (that the table is inside) doesn't grow, so the table is cut off because it's longer than it's container, but not it's container's container.
I will try to make that messy-sounding paragraph into some demonstration HTML or better yet a solution. Not sure how that will go...
Hm... here's a guess: maybe what's happening is that the fightform is still visible.
"still visible", you may ask, "but I don't see anything".
That would be because fightform got turned into a mere white box, and this white box is what's on top of the lower part of the table.
If you see this happening again, try adding a "z-index:99" attribute to the whatif table.
In fact, if that was what was happening maybe my last patch will fix it! (which means that if it gets checked out, you shouldn't use it (until we get more info about all this, that is))
Again, it's just a guess/theory.
"still visible", you may ask, "but I don't see anything".
That would be because fightform got turned into a mere white box, and this white box is what's on top of the lower part of the table.
If you see this happening again, try adding a "z-index:99" attribute to the whatif table.
In fact, if that was what was happening maybe my last patch will fix it! (which means that if it gets checked out, you shouldn't use it (until we get more info about all this, that is))
Again, it's just a guess/theory.
dunno. I was able to reproduce it pretty quickly. But it exists prior to this patch and hasn't been raised as an issue before, so maybe rare? Or not-too-annoying? It's not like it's breaking functionality and it probably only really happens frequently now because of the TCRS ring.
I don't know where KoLMafia sets this, but it seems like actionbar.6.css using visibility:hidden (which creates an invisible box in the box model) when it wants display:none (which treats the element is nonexistent for rendering and box purposes.
I don't know where KoLMafia sets this, but it seems like actionbar.6.css using visibility:hidden (which creates an invisible box in the box model) when it wants display:none (which treats the element is nonexistent for rendering and box purposes.