In And Out

[#1]

Note that the 'stay on page' functionality does not work in all browsers due to limitations of the browser - e.g. Safari.

[#2]

Really, since when? It works for me using Safari v9.1

[#3]

There was a long discussion with @jaread83 on this; apparently Safari has had this issue for quite sometime.  It certainly does not work on iPads.

[#4]

Hi all,

The problems with the 'stay on page' functionality is a customisation I had put in to check if a user was trying to navigate away from a page while composing a reply as our testers wanted a way to provide a warning before potentially deleting an infinished reply. Becuase of the intermittent javascript errors (this is being looked at by Lithium currently as this does not occur on the staging environment) it is interferring with other javascript functions that require it to work.

When the javascript issue has been resolved (not sure if it has yet or not, I will need to speak to @mtrinder or @LouisaMartin to get an update on that), this shouldn't be a problem anymore and should work just like the staging environment. Please do let me know if you still get the errors though, I am logging everything so we can keep a record of things to test out once a fix has been rolled out.

[#5]

@jaread83 We ( @mtrinder ) pushed from Stage to Prod on Friday as per request from Lithium. Matt then tested again and he was still seeing the issues. This has been fed back.

[#6]

Thanks @LouisaMartin. It was me that did the push from staging to the live site on Friday and I know that it didn't resolve the issue. Please let us know if there are any updates on the progress of this rather annoying bug! I can't replicate it for me but i know that @mtrinder could on his machine even though we are using the same browser and operating system.

[#7]

Sorry @jaread83 that's me dismissing you again! Sorry!

'Course, as soon as they come back I'll let ya know 

[#8]

---

@jaread83 wrote:

... even though we are using the same browser and operating system.

---

@jaread83 - I know this is nowt to with me but you may well be using the same OS and Browser but are you both patched to the same level? i.e. Identical version, revision, build numbers for both OS and Browser. Being a Software Engineer I know little subtleties like this can sometimes be an issue.

Edit - Corrected Spelling Mistook.

[#9]

Hi @Anonymous,

Our browsers are the same version but our OS's might be slightly different in version numbers (I think he is running OSX Yosemite). I will check with him to see if there are any discrepencies between our systems.

@mtrinder, can you confirm that you are still getting the javascript issues? Can you post your browser version number too so we can compare? Here is mine:

Operating system: OS X El Capitan Version 10.11.4

Browsers:

Firefox 45.0.2 (latest version)

Chrome 50.0.2661.75

[#10]

Not wanting to teach anyone to suck eggs but a callback to the websocket close() method needs to be added to the onunload page event to close the socket, as at present their simply getting dumped.

[#11]

[#12]

---

@Anonymous wrote:

Not wanting to teach anyone to suck eggs but a callback to the websocket close() method needs to be added to the onunload page event to close the socket, as at present their simply getting dumped.

---

Thanks @Anonymous, I will try this on my custom component on staging. This has been added to my bug list for further development work.

[#13]

---

@jaread83 wrote:

Hi all,

The problems with the 'stay on page' functionality is a customisation I had put in to check if a user was trying to navigate away from a page while composing a reply as our testers wanted a way to provide a warning before potentially deleting an infinished reply.

---

Of course I maybe completely misunderstanding the intention here, but can't this be done by using nothing more than the page's onunload event handler. As I understand it the tabs (Rich Text, HTML and Preview) on the editor don't physically reload the page nor does the User flyout when it's called. So if the user opens their flyout and selects one of the options prior to posting this will results in a new url and as a result the onunload event handler would trap it and the display the confirmation dialog. A simple boolean flag value could be set by the form's onsubmit event to prevent the popup from appearing when the message is posted.

Just a thought.

[#14]

The way you described is pretty much how I have the script set up. There is even a true/false on the submit button to stop the dialog appearing if the submit button is clicked. All of this is within an onunload event. Myself and @Townman went through this and he was the one who suggested it during testing. As he mentions elsewhere, Safari does not recoginise the onunload so safari on desktop and mobile are both stuffed. I would dig up the code and show you but I am unsure if I am allowed to do that.

Moderator's note by Mike (Mav): Full quote of preceding post removed as per Forum rules

[#15]

@jaread83, @Townman - in that case can't you use the beforeunload event that I am sure is supported on all browsers, but I may be wrong.