ID:2546067
 
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
The current method of invoking client-side winset/winget in JavaScript is by setting the window.location to a special URL which calls the respective functions. The main limitation of that method is that IE has an URL length limit of 2083 characters, which can be reached easily when trying to set large values for controls, updating multiple controls in one call or calling verbs with large string args. The same limitations apply to sending Topic data from JavaScript, but that limitation is avoidable by using XMLHttpRequest instead of window.location.
function sendTopicDataOld(data) { // limit of 2083 characters, some of which are already used up by window.location
window.location = "?" + data;
}

function sendTopicData(data) { // limit of ~64182 characters, some used up by window.location
var xmlHttp = new XMLHttpRequest();
xmlHttp.open("GET", "?" + data, true);
xmlHttp.send();
}

Using XMLHttpRequest gives us ~30 times more characters to work with compared to window.location. Unfortunately, this doesn't currently work for winset/winget due to the way HandleLink is called with XMLHttpRequest and how it processes winset/winget links. Using the byond: URL in XMLHttpRequest doesn't work since byond: isn't a proper scheme that IE will accept when calling XMLHttpRequest.open() resulting in an 'Access is denied' error.
+1, had to resort to splitting the calls up and that gets soooo clunky and unreliable sometimes.
I'm a little unclear on something, because the code you've written wouldn't be able to do the winset/winget anyway, which uses a format like:

byond://winset?...

I'm not seeing how you'd plan to work winset/winget into the URL.
As it is right now it's not possible to do winset/winget, so a new format would need to be added that can be handled by the XMLHttpRequest call chain.
The window.location method and XMLHttpRequest are handled through different call chains and as such could be treated as separate cases so perhaps a "?winset?..." format when handled through the XMLHttpRequest could be used for winset instead of being treated as a topic call. Unfortunately I don't think "#" can be used as an identifier since fragments aren't sent with URLs as part of a GET request.
Bumping this, since it would be very convenient to run winset calls via the built-in web server (to better integrate our development tools into dreamseeker), and of course would also raise the payload limit, which you can easily run into if you're updating a lot of elements in bulk.
bump for 515, this would be very helpful for complex interfaces
I haven't read this yet, but I'm bumping it.
Makes so much sense, currently I believe the data is limited to 2086 character, yes? I have a similar issue with client side requests, so far chopped up the requests.