Hammered through 6.1 testing last few days. A major bug (for us anyways) that is still outstanding (resizing tab panels not in sync with window resize):
https://support.servoy.com/browse/SVY-2588
jcompagner wrote:Rossen,
At the moment this freeze happens, can you go to the admin page and dump the stack? So that we can say what it currently does?
This is also a tip for everybody reading this, if in developer (or webclients/server) something really hangs for a while (in what ever form or place, so the developer it self or any debug clients, web or smart) please go to the admin page and dump the stack. Then we can quite easily see what it is doing at that time, To have a bit more info when it takes a bit longer is have a few dumps 5-10 seconds apart.
rossent wrote:
The attached file contains several memory dumps taken 15-20 seconds apart during one of the latest "freezes".
david wrote:Another issue I'd love to get some votes on: https://support.servoy.com/browse/SVY-2678
jcompagner wrote:david wrote:Another issue I'd love to get some votes on: https://support.servoy.com/browse/SVY-2678
this will not be fixed very quickly
We need to do this, because when you do recreate ui we need to have a full new CSS file applied to the current form. (because you can have changed any kind of property for any kind of ui element)
So we need to get rid of the current css file completely, and unloading a css is quite tricky i think in a browser.
thats why we do a full reload so that everything is nice and clean.
http://url:8080/servoy-webclient/formcss/moduleName/formName_t1342416223947t.css becomes
http://url:8080/servoy-webclient/formcss/moduleName/formName_t1342416223947t.css?v=randomStRiNG
jcompagner wrote:That is ofcourse already in place...
Else a browser refresh wouldn't help either.. Because then the browser would cache the css anyway
What do you think that "_t1342416223947t" is?
the problem is that just having a new css, but with the same content (same element id's and so on) will not help because then that new css is just loaded and appended behind the rest (and we hit the Internet Explorer 30 css limit even sooner)
but if the new css has the same selectors as the old on, nothing will change because the browser will just see the old one.
So i guess then every element must have a new unique id, but it could be that we kind of support that now in 6.1, so that could help. But there are just a few issues to solve here
david wrote:I think changing the css file name and changing the get parameter of a css file name is not the same thing.
mattfrizzell wrote:David, After a great number of "hallway sessions" at Servoy World this past year I think the issue of refreshing an entire page in the web client is part of a larger discussion that needs to take place between the community and the devs. There were a lot of ideas on how to get around this behavior, but I think we all are looking for a way to perform actions in the web client without a round trip and a full reload through the use of native Servoy functionality (I know I am). If this a separate thread someone tell me where to put it (watch yourselves!) and we can start sharing ideas on how to make our lives in web client perform as a web page should.
david wrote:Changing the css file name has all the issues you brought up. However, as I understand it changing the get parameter forces the browser to think the css file name has changed so it goes to the server for the "new" css file and reloads the css file with the same name as the file name really hasn't changed.
When web client starts up for the first time, Servoy creates all of the css files with new "_t1342416223947t" in the names, I get that. This works great for clearing out CSS caching between solution updates. However, you don't change the name of the css files on the server when recreateUI() is called -- you change the URL which forces a reload of any new css that has been changed in the css files already created on the server because you're on a new page.
What I'm suggesting is tacking on a random get parameter every time recreateUI() and keep the same URL. These get parameters exist only for that user and session in the client-side code that you output. No page refresh and the browser reloads the "same" css files.
jcompagner wrote:you seem to think when you do this:
<html>
<head>
<link rel="stylesheet" type="text/css" href="mystyle.css?x=1" />
<link rel="stylesheet" type="text/css" href="mystyle.css?x=2" />
</head>
the browser is really loading in one of that file. But for the browser it are just 2 files, both css files are applied (and in this case if it is purely static it is the same)
But both are loaded.
So to really have this working you have to really delete the link node from the dom or set the href property of the right node to zero (or maybe update it to a new one)
But this is quite change in a specific behavior that we have to implement then
Users browsing this forum: No registered users and 7 guests