Bug - Fixed Missing relay script dropdown

Captain Scotch

Captain Scotch

New member
Hey folks!

I've been getting a persistent frustrating issue where the relay script dropdown disappears when using awesomemenu.php; screenshot includes what it looks like without the menu. I tried expanding it to fullscreen it and it definitely is not present. I've also attached the debug log.

In terms of fixes, here is what I generally try:

- First, reload the frame
- Second, reload the page
- Third, logout/login
- Fourth, close mafia and reopen it
- Fifth, delete mafia install and reinstall it
- Sixth, backdate mafia
- Seventh, update mafia again

This happens roughly 1-2 times a week. It usually fixes either on the fourth step or the seventh step. I really do not know what's going on, and I can't reproduce it, because I have no idea what causes this whatsoever... but still wanted to report it. Hopefully others can figure out what exactly is going on, as I'm at a loss.

Thank you for all you do! :)

-- Scotch

EDIT: I have a new way to fix it -- if you swap from awesomemenu.php to link or dropdown, then swap back, the script menu comes back. No idea why that works!
 

Attachments

Changed the tag because the label Bug will get more attention. "Can't Reproduce" devs and others will choose to spend their time on something that can be reproduced/

if you swap from awesomemenu.php to link or dropdown, then swap back, the script menu comes back.
Click to expand...

That can be a sign something wasn't set (or got unset) and then the swap set it.
 
If you press the "Edit" button in the Awesome menu, it shows the awesome menu editing interface and the script menu.

If you look at "Awesomemenu.php", it writes the following CSS

#config {font-size: 11px; display: none; }

You can try option #9, "press the Edit button in the AwesomeMenu".

My guess (and it's only a guess) is that something recently changed in Awesomemenu.php and it's breaking TopMenuDecorator. Our code to do this isn't very new.
 
I started looking at your DEBUG log and it seems like our trigger - a div with id=“awesome” - is there, as expected. However, although we stuck in an import of basics.js there, none of the rest of the decoration. In particular, the scripts menu.

I’ll write some tests with HTML from my working awesomemenu and your failure, and will see if I can come up with an explanation of what else could go wrong.
 
I wrote a test which accepts the HTML returned by awesomemenu.php and calls TopMenuDecorator.decorate on it.

For now, it simply confirms that we did SOMETHING to it.
I suppose that it could confirm that it did exactly what we expected, but that would require mocking up installed scripts, and so on.

In any case, both your and my HTML got modified appropriately.

I then made tests in which KoLmafia THOUGHT the top menu style was UNKNOWN, NORMAL, or COMPACT, but was actually given the awesomemenu.php response.

For UNKNOWN, it did not put in anything.

For NORMAL and COMPACT, it found an "appropriate" place to insert stuff.

I conclude that, somehow, KoLmafia forgot that you had the FANCY style of topmenu.

This would explain why switching to links and back would fix it, since we learn the menu style from watching what you do on the account options.

Time to try to figure out how/why we'd reset your top menu style to UNKNOWN.
 
And I'm not seeing that anywhere.

We deduce the TopMenuStyle when we parse the response of a topmenu request.

topmenu.php
-> redirects to awesomement.php
(we follow the redirect)

and deduce style like this:

Code: 
    GenericRequest.topMenuStyle =
        text.contains("awesomemenu.php")
            ? TopMenuStyle.FANCY
            : text.contains("Function:") ? TopMenuStyle.COMPACT : TopMenuStyle.NORMAL;

So, does the responseText to awesomemenu.php contain the string "awesomemenu.php"?
Yes, it does. All over the place.

Refreshing Session Data would reload that page, so that, if nothing else, should have updated your known menu style.

And there is literally nowhere that sets the style to UNKNOWN; it starts that way, and is changed to something else, but never back.

This is puzzling.
 
I tried a lot of things as well, and saw it sometimes. I was in options switching between styles, I reloaded the page.

It happened maybe one time in 10. I have two sets of source from the web inspector. One with it in the right place, one without it.

In my case, it's not missing, it's inside a hidden element, the id="config" block, which is hidden until the user pressed edit in the Awesomemenu.

Here's my occasionally reproducible test case. It's probably not the only test case, but it happens every time.
1: edit the awesome menu
2: Add a macro icon and drag it to the middle.
3: without saving, reload the page.

To undo:
1: Edit the awesome menu
2: reset menu

I'm wondering if the awesome menu is, for instance, doing something like hiding all tables or some exciting bit of code like that.

1689960084613.png
 
I have no idea what "editing the awesome menu" means; I have literally never done that.
Adding an icon, giving it a location to submit, giving it an icon, moving around your icons?
KoL undoubtedly thinks it has the entire topmenu area to work with.
There is CSS at the top telling what to do with its various divs.

Notice that when we decorate awesomemenu.php's response, we create our own div and insert it right before KoL's div with id="awesome".
We give it an absolute location in the "div" itself; we do not add it to the CSS, although we probably should.
Perhaps we could set it up such that KoL will know that our div is not part of what IT controls.
Perhaps somebody who understands CSS should look into that. ;)
-----
My tests show that there doesn't seem to be any issue with what KoL gives us for the awesomemenu. Both Captain Scotch and I got a response text that we are perfectly happy to add menus to. It doesn't deduce what kind of menu it is - although if you look at MoonPhaseRequest, it certainly could do that. It places the decoration based on whatever GenericRequest.topMenuStyle claims it is.

THAT could stand to be improved, but if our decoration is actually on the page but the browser is hiding it, ugh.

Scotch's DEBUG shows the HTML received from KoL and also the decorated text we sent to the browser - which does not include our script menus. That is really confusing, since my test indicates it should have worked.

I'll submit my tests as a PR. Perhaps I will augment it with detecting the menu style from the text before decorating, although that, in general, would essentially always be completely wasted text searching; detecting style from MoonPhaseRequest and actions in the account menu should suffice.
 
Veracity said:
I have no idea what "editing the awesome menu" means; I have literally never done that.
Adding an icon, giving it a location to submit, giving it an icon, moving around your icons?
Click to expand...
Sorry, to be clear, I meant "pressing the button labelled "edit" (vertically)

1689986877622.png

Veracity said:
KoL undoubtedly thinks it has the entire topmenu area to work with.
There is CSS at the top telling what to do with its various divs.

Notice that when we decorate awesomemenu.php's response, we create our own div and insert it right before KoL's div with id="awesome".
We give it an absolute location in the "div" itself; we do not add it to the CSS, although we probably should.
Perhaps we could set it up such that KoL will know that our div is not part of what IT controls.
Perhaps somebody who understands CSS should look into that. ;)
Click to expand...
I can wrangle CSS pretty well. There's some janky stuff in awesomemenu.php, and what I really want to see is what they're doing with the event listener on the edit, or maybe the onLoad event. Still poking at this.
Veracity said:
-----
My tests show that there doesn't seem to be any issue with what KoL gives us for the awesomemenu. Both Captain Scotch and I got a response text that we are perfectly happy to add menus to. It doesn't deduce what kind of menu it is - although if you look at MoonPhaseRequest, it certainly could do that. It places the decoration based on whatever GenericRequest.topMenuStyle claims it is.

THAT could stand to be improved, but if our decoration is actually on the page but the browser is hiding it, ugh.
Click to expand...
That's my take as well, it's not that it isn't there, it's just that sometimes it's inside something that's hidden. But why sometimes?
 
I experienced this a few times now. Closing and reopening KoLmafia is the only thing that fixes it.

When it fails, two sections are different. Below is the HTML source for awesomemenu.php
1690046985210.png
1690047007006.png
The left-hand side is when it doesn't load, and the right-hand side is when it loads.
 
The left is when TopMenuDecorator thinks we have TopMenuStyle.NORMAL and it inserts the scriptmenu at the end of the final table.
The right is when TopMenuDecorator thinks we have TopMenuStyle.FANCY, and it inserts a div at the beginning.
In Captain Scotch's DEBUG log, there is no script menu, indicating that TopmenuDecorator thinks we have TopMenuStyle.UNKNOWN.

As mentioned, the only code to reset topMenuStyle is in account options or MoonPhaseRequest.

Literally the only place where we look at what your TopMenuStyle is in TopMenuDecorator.
- We could detect it from the text we are given
- We could assume that awesomemenu.php is alway FANCY (duh).

I guess the motivation was to avoid a string search when we can detect the style only the first time we look at the topmenu or when you change it in the account menu. But, somehow, in an unknown way, the style is resetting incorrectly. That irritates me.

I think detecting it from URL and responseText each time we decorate the topmenu is safest.
 
Veracity said:
I guess the motivation was to avoid a string search when we can detect the style only the first time we look at the topmenu or when you change it in the account menu. But, somehow, in an unknown way, the style is resetting incorrectly. That irritates me.

I think detecting it from URL and responseText each time we decorate the topmenu is safest.
Click to expand...
That seems like the best place to detect it.

I am still trying to get a reproducible use case. Sorry this is being difficult. One of the issues is that the frame size is too small when we insert the menu if there's only one row or there are two rows with the text awesomemenu. If we could alter the frameset in game.php with id=mainset from 50 to something bigger, that would be a help. That's probably a less-vexing bug, but is getting reset and hiding the scripts menu.

My latest try at reproducibility is still failing, but I have noticed that I can cause it sometimes. By choosing Options>Enable Mobile Mode will re-load topmenu.php and awesomemenu.php, and that sometimes if you have pressed the Edit button on the right hand side of the awesome menu (near the moons) and done some editing, that reload triggers the incorrect behavior. What generally "works" is doing a bunch of those changes until I see the menu disappear.

I was also trying to figure out if this was also interacting with client-side javascript, but I captured a HAR file and it's happening in the decorator in Java.

Would it be useful to add an id to our div, possibly id="fancyscriptmenu/"compactscriptmenu"/"standardscriptmenu"?
 
So, I tried the new version.

I couldn't break it, but I did see the error message. The fix seems to be working so far for me for this test case (I don't think this is the only path to the problem, though). A few times KoLmafia detected NORMAL when it was FANCY and KoLmafia thought it was FANCY.

This is everything in my session log from the last message of my actual run [461] to my just-now experiments with FANCY/NORMAL
Rich (BB code): 
[461] Rest in your bed in the Chateau
WARNING: updated modifier not in modifiers.txt: Item:[10732]
You are currently a member of Bonus Adventures from Hell
We think topmenu style is FANCY but it is actually NORMAL
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is FANCY but it is actually NORMAL
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is NORMAL but it is actually FANCY
We think topmenu style is FANCY but it is actually NORMAL
We think topmenu style is NORMAL but it is actually FANCY

movie of what I was doing in case that context helps as well. Full session log for the same reason.
Is there anything else you can think of I could test?

 

Attachments

Last edited:
Whoa.

The "new version" is r27502.

That looks at the actual text of the response it is given and deduces the menu style in the same way the MoonPhaseRequest does.
If it does not agree with what it expects, it logs a message and sets the style to what it just detected - which should let it add the script menu in the appropraite way.

It COULD look at the URL - i.e. awesomemenu.php or topmenu.php - and decide that awesomemenu.php is always FANCY. But, just in case awesomemenu.php returns something that is not so awesome, it doesn't.

I will look at your movie and your DEBUG log.

Edit: actually, that is a session log.

I'd like to see a DEBUG log of editing the menu like that.
We only decorate the topmenu when the Browser submits a request to topmenu.php or awesomemenu.php.
All that editing was surely happening in Javascript on your browser.
I expect that it only submitted a request to KoL to upload the changes when you told it to save.
What URL did it submit? Was it, perhaps, "awesomemenu.php?other-arguments-here"?
 
When I "clicked to exit" edit mode, it submitted:

awesomemenu.php?existing=&actiontype=go&icon=seasidetown&go=place.php%3Fwhichplace%3Dmonorail&macro=&name=

The response had the full awesomemenu with the newly added icon.

Looking at your list of messages, I can understand:

FANCY -> NORMAL
NORMAL -> FANCY
... if KoL sent two successive menus of different styles

NORMAL -> FANCY
... but how did this happen? How did we set it from FANCY to NORMAL before that refresh?
 
I was also looking for events attached to the elements there, but I think some of it is round-tripping to the PHP server.

I'll grab debug as well. Would trace be of any help?
 
Oh, the version on mine is because I'm working from my IDE. That version number is off, but I was testing with your development branch before the PR was approved. Otherwise, I'm working in Preferences.java and PreferencesTest.java, so it shouldn't have any affect on this testing, but if you think it would be better to test in the released version, I can.

Anyway, here is the debug log where I think fetching icons is causing the normal/fancy issue, which may not be the thing we're looking for. Maybe we should abort the decoration if we're getting ?icons=1

Movie to go with the debug log:

(Edit: Debug, not an old trace)
 

Attachments

Last edited:
Ha. awesomemenu.php?icons=1 returns a JSON array.
We'll look for a closing "tr" tag and will find none, so we will not actually decorate the buffer, but we will change the menu type.

Edit: r27503 does not change TopMenuStyle when loading awesomemenu icons.
 
Code: 
awesomemenu.php?pwd&action=reset
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?pwd&action=toggle
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?icons=1
(ignored)

awesomemenu.php?existing=&actiontype=macro&icon=demonhat&go=shop.php%3Fwhichshop%3Dolivers&macro=h%2Cglkgh&name=
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?existing=&actiontype=go&icon=seasidetown&go=shop.php%3Fwhichshop%3Dolivers&macro=&name=
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?existing=&actiontype=go&icon=seasidetown&go=shop.php%3Fwhichshop%3Dolivers&macro=&name=
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?existing=&actiontype=go&icon=seasidetown&go=account.php&macro=&name=
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?pwd&s=10%2C0&e=13%2C1&action=drag
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?pwd&s=13%2C1&e=35%2C0&action=drag
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?icons=1
(ignored)

awesomemenu.php?pwd&action=reset
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)
All normal.

Code: 
main.php
charpane.php

awesomemenu.php?existing=&actiontype=go&icon=seasidetown&go=gnomes.php%3Fplace%3Dmachine&macro=&name=
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?existing=8%2C0&actiontype=go&icon=seasidetown&go=campground.php%3Faction%3Dtelescope&macro=&name=
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?pwd&s=8%2C0&e=13%2C1&action=drag
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?existing=&actiontype=macro&icon=seasidetown&go=shop.php%3Fwhichshop%3Dolivers&macro=jhkh&name=jgflygoy
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

awesomemenu.php?pwd&action=toggle
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)

account.php
charpane.php

awesomemenu.php?pwd&action=toggle
(has link to awesomemenu.php -> we believe it is a fancy topmenu)
(has <div id="awesome" -> we know where to insert script menu)
We think topmenu style is NORMAL but it is actually FANCY
Conclusion:

When you visited the account page, we (supposedly) parsed the radio buttons for the topmenu style and came up with "NORMAL".

This should be easy enough to fix.
 
You must log in or register to reply here.
Back
Top