[FIXED] - See last post
Code:
Problem description:
http://www.byond.com/developer/Shadowdarke/sd_Alert
Using an HTML menu interface for games has worked pretty well for me. An HTML menu is way more stylistically awesome than the default option, in my opinion.
The menu works just fine on the webclient under the SD_ALERT_LINKS option
However, there's only one problem:
it opens a new tab everytime on the webclient. I'm not really sure what's triggering it, but at least in my game it's causing some big issues.
Is there a way to fix it anyone knows about? The fact the behavior only occurs on the webclient and not dream seeker might imply something with Topic() might be the culprit...
EDIT: I want to note it seems that a recent update caused this behavior. I think the tabs popping only occured like 5 updates ago because they used to work just fine without the tabs issue.
ID:2111491
 Jul 5 2016, 2:45 pm (Edited by moderator on Nov 3 2016, 9:35 am)
|
|||||||||||||
| |||||||||||||
It seems to be happening in older versions too...
What happens is the menu works, the choice works. It works just fine. The only thing is, it creates a new tab with an exact copy of the menu and only the menu in addition to working. Like, the function works, Topic() works just fine and the game accepted the choice, it's as if the new tab is just created for some odd reason. I'll see if there's a workaround, other than to not use HTML menus.. It's odd. Why does the webclient even have the ABILITY to create a new tab? I thought it didn't have the power to do that, but I guess it does. I suppose there's possibly some development reasons it could work and I could see a new tab being used for games, but if I could just figure out what block of text was actually doing it... (probably the javascript call) | |
WAIT, I think I just found out the exact line that creates a new tab
Del() if(target) target << browse(null,"window=\ref[src]") winset(target, "\ref[src]", "parent=none") ..() It's possibly this very line that triggers it. In dream seeker, browsing 'null' deletes the window. I wonder if browsing 'null' creates a new tab in the webclient? Time to test. | |
I'm pretty sure the winset() already deletes the window, so the browse() line isn't actually necessary. Last resort would be to use winshow("\ref[src]", FALSE) to hide it before the winset().
| |
i'm still trying to figure out a solution to this issue, other than of course to not use links.
| |
After doing some trial and error on this bug, the issue seems to be the nature of links themselves.
Implementing a clickable link in a HTML window seems to open a new tab for some reason, this behavior is exclusive to the webclient. | |
FOUND THE SOLUTION!
I finally fixed it! I had to change the href element of all links in my window Originallly it was href=# I changed it to: href=\"javascript:void(0);\" Works fine now. href=# doesn't work properly on webclients and spawns the content in a new tab, which is actually semi-unique functionality as it would allow you to have webclient users get new tabs opened in their windows, though some devs might see this as being intrusive it depends on implementation Thanks guys for the help! | |
Ah. That's quite helpful to know. I'll move this thread to Beta Bugs so I know to look into it.
| |
I can take a look at it sometime, but I'm pretty busy whipping 511 into shape.