Save/Cancel buttons sometimes working, sometimes not (Part 2)

[Stu]

So I've done a bit more investigation into this. The form has Send Stage To Debug ticked.

Took an example of the save button working and one not working, and compared the debugview output.

The difference, as follows, seems to be the 'stageVALIDATE' and the 'StagePost' do not get run when the save button doesn't work.

Code: [Select]

START p_stage=[2050 net:web:StageVALIDATE net:web:Change] Event=
END p_stage=2050 net:web:StageVALIDATE net:web:Change Event=
START p_stage=[4098 net:web:StagePOST net:web:Change] Event=
END p_stage=4098 net:web:StagePOST net:web:Change Event=
Bruce - Can you think of any reason why the Validate/Post stages wouldn't get run?

Could it have something to do with the form/save button info being overridden somehow, maybe by stuff in popup or child browse/form functionality?

[Poul]

Hi Stu, to give you some moral support.

I am seeing some strange things recently that include the Cancel/Save issue, during my recent upgrade foray.

I have a  C9.1 with NT 8.64 - Was My Base - solid for this stuff - I use it as a reference to compare code and behaviour against,
I have a  C9.1 with NT 9.13 -  Upgraded and Tweaked
I have a  C10.0.12278 with NT 9.13 -  Upgraded Tweaked.

(I need to do some webservice stuff with JSON, so i want a Current version, but I am still holding to the C9.1 version until i am comfortable with  C10, but all three are essentially the same)

I have not had this problem reported in production _ which i change infrequently, but in development this issue has been intermittent, and spooked me a bit, i originally thought it was my simply touching a template and what i thought was a benign recompile would change the behaviour, and i could not undo it. (I actually did some reverting and restoring, to try and get my headaround it ) I had something that was not working last night , but worked fine first thing this morning.

As i moved between versions (testing from the same browser) I found i could fix and break the save/cancel behaviour on a popup, just by compiling and launching different versions of the app.

My belief is it is circumstantial relating to Sessionvalues, Browser Caching AND ServerState persistence, (Saving session values between compiles etc). When the poup is rendered  no sign of an error, other elements on the form work - except for save and cancel.

Refreshing the Browser and Deleting the Serverstate.xml (or NOT Saving) do seem to help. Launching an alternative browser helps.
I do not use Multi-dlls and each server is in its own folder (for Serverstate)

But i am testing against different servers and multiple compiles from the same browser often the same session, Refreshing when i think it warrants it, launching another browser when it seems to misbehave.

I only started using the Serverstate stuff recently, (to my mind that is something quite new that i suspect contributes to my issues), i would be interested in knowing if you are preserving  ServerState between runs and how often your server/application is restarting  and how long your session timeout is - could you correlate any of this to a user reporting a problem?

Note: the Save/Cancel issues shows on 2 of my main popup windows, its unclear to me if it affects other things.

poul

[Stu]

Hi Poul,

Interesting, very interesting!

So.

1. I don't use the serverstate function yet. I tried a couple of times, but .. My big intranet is so big and customised that a lot of stuff didn't persist through the restart (ie memory files). Wouldn't be hard to get working, just .. Time. Don't have it yet to get it working to where I'd like it to be.

2. I do a bit of trickery to get the server timeout to keep refreshing if the browser stays open. This is fraught with security issues, but so far the lack of annoyance at having to log in three or four times a day has outweighed the security issues.

So according to what you're saying, there might be something there.

3. I restart usually once a night, but it's at nighttime, nobody logged in.

JUST NOW

* I've just had the issue occur, but slightly different, and I got the user to call me and monitored DebugView as she went through the process.

The issue was slightly different in that this time the window was closing BUT nothing was being saved. This is a file record form window.

Even though this time the window closed (in the example above it wasn't closing), the "Send Stage To Debug" was showing exactly the same log.

When things aren't working, the net:web:StageVALIDATE net:web:SetPics event fires, but the net:web:StageVALIDATE net:web:Change and net:web:StagePOST net:web:Change events do not fire.

I then tried myself three times in a row, doing slightly different things. No dice.

Then a couple of minutes later I tried one more time, doing the same process, and it saved.

INTERESTING #1: The user said that she has to scroll down to get the save button on her screen. Could this be an issue?

It's definitely not an issue on my screen, and I experience it, so there's that. Probably a red herring.

INTERESTING #2: This issue occurs X times and then on time Y it goes away and everything works as per normal.

-

I'm still wondering if your theory about the sessions and timing and server state could be affecting here, even though serverstate isn't being used.

It's such a wierd occurance, a problem that goes away if you do the process enough times. What is "enough". And what might be happening between Y-1 and Y times to make it work?

[Poul]

I never see it come and go with the same Instance of the server and browser session, its the  restart of the server (like one might do during development) when the issue get triggered and it appears to remain in effect and i thought i had broken something. But i actually had one browser on one station working and one on other not  so ...

Like you i originally assumed some javascript error or bad xml/html that breaks the ajax stuff got introduced, but i think that its more subtle than that.
Because of the repeatable nature of when its working and when its not, i don't think it is the data, or the static elements of the page generation.
But some state conflict between the values and the session values, or something not set right for the popup behaviour.
 
In my case it appears i can defend it by "don't do that" - ie:don't  preserve the serverstate, but i cannot say it definitely is the problem,
If i see it occur outside of that reason, i will  make a determined effort to duplicate this.

The fact that your user can after some 'fiddling' get it to behave is interesting, not my experience, but perhaps i was freaking out to soon ....

if our issues are related it sounds like the circumstances are quite different.

poul

[Poul]

I just create the situation where i have one browser on one workstation working and one on another that is not,
With Firebug on Both, i can compare sidebyside, something that seems interesting

on the machine that works the browser send this to the server:

Code: [Select]

GET /SetSessionValue?popup_updshipsum=1&_ajax_=1 HTTP/1.1
Host: devmachine:90
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Accept: */*
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: http://devmachine:90/UpdProjectDeal
Cookie: SESSIONID=Ybr9JZImwQqMtTEF
Connection: keep-alive

On the machine that does not work Looks like this:

Code: [Select]

GET /SetSessionValue?popup_UpdShipSum=1&_ajax_=1 HTTP/1.1
Host: devmachine:90
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
X-Requested-With: XMLHttpRequest
Referer: http://devmachine:90/UpdProjectDeal?Change_btn=Change&PD__GaNbr=19398
Cookie: SESSIONID=fe1PD9YxFp9W3nod
Connection: keep-alive

Note: the case difference, (popup_UpdShipSum)  why is that different?
these are the same server running the same sequences of keystrokes to the same data,

Referer  has parameters ( ?Change_btn=Change&PD__GaNbr=19398)

poul

[Bruce]

I'll have to dig a bit to see why they are different Poul, but thanks for the info, I'll dig a bit deeper to see if it's material to the problem at hand.