Bug - Fixed extra intraneous scrollbar

fronobulax

Developer
Staff member
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.
 

fredg1

Member
I'm just reporting what I see. You all can decide if it needs more tweaking.

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)
 

fredg1

Member
Ok, I managed to reproduce the Palindome (thanks The Dictator for the HTML).
2hmCRr8R04.png

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:firefox_8eJfSTSRzK.png

The situation is solved by giving the pop-up a z-index of as little as 1: sZeI8LTzFg.png

Here's the patch that does that: View attachment UseLinkDecorator.java.patch

Tested
 
Last edited:

MCroft

Developer
Staff member
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...

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.2
Here you can see that the table is cut off at the bottom.
Screen Shot 2020-09-23 at 9.59.35 PM.png
If you scroll the window, then more of the table smoothly becomes visible
Screen Shot 2020-09-23 at 9.59.52 PM.png
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.
Screen Shot 2020-09-23 at 9.43.32 PM.png
 

Attachments

  • Screen Shot 2020-09-23 at 9.41.40 PM.png
    Screen Shot 2020-09-23 at 9.41.40 PM.png
    304.5 KB · Views: 6

MCroft

Developer
Staff member
It's possible that it could be Safari. But if we determine that, I'll file a bug with them. :)
 

fredg1

Member
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):
firefox_LwAP9kFPFv.pnggOpA9DQY1C.png
(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?
6XbMi5Hzgl.png
 

Veracity

Developer
Staff member
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!
 

fredg1

Member
Me? Skill? HAH, I only learned ... ANYTHING about CSS/Javascript 1.5 week ago, while trying to add a minimize feature to TourGuide.
I got pretty much everything from Zdrvst, Phillamon, dex von neumann and Worthawholebean; I'm actually super new to all this :v
 

MCroft

Developer
Staff member
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.
box model.png

These images are the fight form source and CSS
fightform source.pngfightform hideform CSS.png

These images are the whatif table source and CSS
source whatif2.pngcss table whatif2.png
 

fredg1

Member
Just to be sure: fightform is what happens when you don't use the CAB, right?
...but then how is the "cut" happening when you didn't use it (the fightform, I mean. i.e. "when you did use the CAB")..?
 
Last edited:

MCroft

Developer
Staff member
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...
 

fredg1

Member
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.
 

MCroft

Developer
Staff member
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.
 

MCroft

Developer
Staff member
fred, visibility hidden creates an invisible box, which matches what you're saying.

I can apply your patch, but not until tomorrow. It's 2:30 here and I should be asleep...
 
Top