Very well!

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

@test looks cool on FF here (using the close button). But dont work on closing the browser window.

On Chrome it don't work with the close button but on closing the browser window.

I think this is a browser specific issue how they handle such things?

@zero-24 close button -> I meant to write current tab close button...

thanks @dgt41 looks like a cache issue :D ok now at my end.
But please double check the save and save as copy button at your end. Here i also get the warning message in FF

Please no. Personally speaking I would hate it

On 17 October 2014 14:14, zero-24 notifications@github.com wrote:

thanks @dgt41 https://github.com/dgt41 looks like a cache issue :D ok
now at my end.
But please double check the save and save as copy button at your end.
Here i also get the warning message in FF

—
Reply to this email directly or view it on GitHub
#4773 (comment).

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

@brianteeman Why? For people using correctly the software, this will never popup.

@zero-24 I get that as well, I am on it!

great feature :)

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

the feature works well when cliking on the close button and the previous browser button but it doesn't works when closing the browser tab !

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

Confirming on editing article, menu and category, also when closing browser tag (Chrome 38.0) I get a message.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

@dgt41 please can you look at the browser tab issue from @ghilo25 before we can commit this

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

@brianteeman Pretty please DONT commit yet. Firefox behaves erratically on save as, save and close and save + new! I need some time to figure out why.

Thats why I didnt mark it RTC.
I will however remove the test results so that your new code (when it comes) is retested

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

Best to close this one for now I think
On 18 Oct 2014 18:13, "Dimitri Grammatiko" notifications@github.com wrote:

Update:
The Firefox erratic behavior on redirects and onBeforeUnload is well
known bug, which Mozilla won’t fix. Ref:
https://support.mozilla.org/en-US/questions/987018
http://forums.mozillazine.org/viewtopic.php?f=9&t=2806589

The other way to get around this is to use EventListener, but then IE8
doesn’t support that.
In this page:
https://developer.mozilla.org/en-US/docs/Web/API/EventTarget.addEventListener
there is a compatibility code for IE8.
But this option (using EventListeners) is way off my league!

Bottom line
If there is a javascript guru that can fix this, please take over
otherwise let’s close this [image: ]

—
Reply to this email directly or view it on GitHub
#4773 (comment).

@brianteeman

Thanks for working on this sorry it didn't work out
On 18 Oct 2014 20:30, "Dimitri Grammatiko" notifications@github.com wrote:

Closed #4773 #4773.

—
Reply to this email directly or view it on GitHub
#4773 (comment).

@betweenbrain I think I fixed it!
@ghilo25 @zero-24 Can you test it one more time?

I don't think you want to change 47 files, are you?

@Bakual I have to redo this, right?

Looks like. But you don't necessary need to create a new PR.
I would do:
1. Create a new local branch whatever
2. Cherry-Pick the correct commits from warning_msg into whatever (or do it fresh)
3. Force-Push whatever to origin:warning_msg, overwriting the existing branch there.

@Bakual is this ok now?

@dgt41 Looks perfect so far. Waiting for Travis to finish

moving also on Jissues back to open. Looks like this is missing

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

Set to "open" on behalf of @zero-24 by The JTracker Application at issues.joomla.org/joomla-cms/4773

@zero-24 ????

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

@test successful on

• current FF with "Close the Browser Tab" and "Back Button" @note: Here it ist a browser only message (no Joomla Text but i think this is a browser implementation)

• current Chrome with "Close the Browser Tab" and "Back Button" (here we see the joomla message text)

• current Opera with "Close the Browser Tab" and "Back Button" (here we see the joomla message text)

• IE11 with "Close the Browser Tab" and "Back Button" (here we see the joomla message text)

We need to test the other Supportet Browsers as well (IE8 + IE9 + IE10): http://docs.joomla.org/Joomla_Browser_Support

But for me all its ok now thanks @dgt41

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

@zero-24 it is documented that FF will NOT display any message (or any text supplied) https://developer.mozilla.org/en-US/docs/WindowEventHandlers.onbeforeunload
Nothing we can do here.
Also IE should not have a problem with this as it was fully supported from IE ver 6

thanks again @dgt41 so we need only one more test.

@test
Works here.
As the message in Firefox comes from the app itself, I do not know if it is translated in other languages.
(message displays in English here as I use an English version of Firefox)

Hmm, I see another issue, specially for testers: It also displays the message when refreshing the page.

Hmm, I see another issue, specially for testers: It also displays the message when refreshing the page.

@infograf768 i think this is expeced behavior maybe we can add a option to disable this feature for testing?

As the message in Firefox comes from the app itself, I do not know if it is translated in other languages.
(message displays in English here as I use an English version of Firefox)

Same here with German FF --> German Message. So it is ok

@infograf768 i think this is expeced behavior maybe we can add a option to disable this feature for testing?

That would be awsome, but I can hear already people shouting if we add a new Parameter, although that one would be for the template style itself and not in Global Config

@infograf768 Message should fire on 3 occasions: hitting the back button, closing the window (tab) and refreshing the page. Should never fire on any toolbar button or a form submission, which is the proper way to exit the edit screen.
About the switch: we can tight it to debug?

@dgt41

About the switch: we can tight it to debug?

possibly.

@zero-24 @infograf768 I went ahead and coupled the functionality with debug mode (it works when debug is off)

Please also debug_lang

@infograf768 with && or || operator?

if (<?php echo JFactory::getApplication()->get('debug'); ?> === 0 && <?php echo JFactory::getApplication()->get('debug_lang'); ?> === 0)

or

if (<?php echo JFactory::getApplication()->get('debug'); ?> === 0 || <?php echo JFactory::getApplication()->get('debug_lang'); ?> === 0)

|| (or operator)
I explain why: Translation Teams (and testers) may need to check their translations on the fly and it would really be bothersome to click each time in the popup

@infograf768 Fair enough, I realize that when debuging some features can be really painful…
Do you mind if I declare those two php variables like debugMode and debugLangMode` in the top of the file so that this line will be much sorter?

do as you feel :)

@test still successful with lastest changes. On more tester for RTC please.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

OK here. I let to PLT the last word on this.

To get a word from the PLT on this, we probably should inform them ;) @Bakual @chrisdavenport @dbhurley Can we move this to RTC?

Looks good to me.

This comment was created with the J!Tracker Application at issues.joomla.org/joomla-cms/4773.

I'm quite sure I will hate it when testing things. But I can see the improvement as well.

@Bakual No pain, no gain. I guess ????

The failure is simply because Travis couldn't connect to GitHub. Please test this PR again to make sure the code still works as expected. Thanks.

This thing is a godsend to me!

@test success on IE11, FF 34.0, Chrome 39.0.2171.71 for all supported conditions

@dgt41 Confirmed: last "glitches" are a thing of the past...
@test success

@roland-d is there a PLT decision for this? Shall I keep it open?

Personally (non-PLT decision) this shouldn't be a template behaviour in all cases where the menu is hidden. But it should be component by component. Because some 3rd party components may hide the menu but have their own version of this message etc. but in cases such as article editing I like the idea!

@wilsonge Do you want me to introduce an option similar to hidemainmenu e.g. jailedform and tight it to this behavior?
Of course I’ll force all the core singular edits [that might end up with a need for check-in] follow this new behavior…

@dgt41 Dimitris, we have 20 views with JFactory::getApplication()->input->set('hidemainmenu', true); Will this mean to add JFactory::getApplication()->input->set('jailedform', true); to those 20 views? Quite feasible I would say, and this will give more flexibility and assure we don't break something else...

Cheers! Sergio

@wilsonge I had an epiphany: how about introducing a behavior.lockedin ?
Pros:
This way the behavior is not coupled to any template
We can use it in front end as well
Cons:
One more js file
One more http request

A new patch that will be per component is on its way thus I am closing this one