We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 3749
    • 24,544 Posts
    I'm seeing this on one install of MODX 2.2.8, even with Romain's fix. I think it may be a problem with Chrome.
      Did I help you? Buy me a beer
      Get my Book: MODX:The Official Guide
      MODX info for everyone: http://bobsguides.com/modx.html
      My MODX Extras
      Bob's Guides is now hosted at A2 MODX Hosting
      • 28840
      • 46 Posts
      Quote from: opengeek at Jan 25, 2014, 12:24 AM
      I have not been able to identify the source of the problem yet. I have experienced it in some situations and not in others.

      Because this problem is showing up in too many environments, in addition to some issues with the phpthumb library upgrade, I'm likely going to revert this change (or make it optional if possible) and put up another patch release for 2.2.x until a more agreeable solution can be found.
      I just reinstalled the whole thing on 2 servers and I upgraded it on modxCloud. Now it happens in only one scenarion - when you change the resource template and page auto-refresh I get the firefox popup.

      Also one more thing - when I comment out the following:

      /* if (!Ext.isIE) {
              Ext.EventManager.on(window, 'beforeunload',function(e) {
                  MODx.releaseLock(this.config.resource);
                  MODx.sleep(400);
                  return false;
              }, this);
          } */

      in resource/update.js it goes away.
      Sumoborac [ed. note: sumoborac last edited this post 10 years, 3 months ago.]
        • 24983
        • 59 Posts
        This fix hack did the trick for me in MODx 2.2.11.

        https://github.com/modxcms/revolution/blob/release-2.2/manager/assets/modext/widgets/resource/modx.panel.resource.js#L66-69

        I.E comment out the following part (around line 65):

                    // Prevent accidental navigation when stuff has not been saved
                    /*var panel = this;
                    window.onbeforeunload = function() {
                        if (panel.isDirty()) return _('unsaved_changes');
                    };*/


        Remember to force refresh (ctrl+f5) your manager for the fix to take effect. [ed. note: rich last edited this post 10 years, 3 months ago.]
          • 3749
          • 24,544 Posts
          Sadly, that doesn't fix it in 2.2.8.
            Did I help you? Buy me a beer
            Get my Book: MODX:The Official Guide
            MODX info for everyone: http://bobsguides.com/modx.html
            My MODX Extras
            Bob's Guides is now hosted at A2 MODX Hosting
          • Quote from: rich at Jan 25, 2014, 10:03 PM
            This fix did the trick for me:

            https://github.com/modxcms/revolution/blob/release-2.2/manager/assets/modext/widgets/resource/modx.panel.resource.js#L66-69

            I.E comment out the following part (around line 65):

                        // Prevent accidental navigation when stuff has not been saved
                        /*var panel = this;
                        window.onbeforeunload = function() {
                            if (panel.isDirty()) return _('unsaved_changes');
                        };*/


            Remember to force refresh (ctrl+f5) your manager for the fix to take effect.

            Yes, removing the intentionally added feature will indeed make it go away ~_~ That's not a fix.

            I'm working on a fix that leaves the feature in place but gets rid of some things reported here. So far I've added a setting (confirm_navigation) that will allow you to disable it completely without hacking core files.

            I also found the root cause of the popup showing up in Firefox (MODX 2.2.11). It seems that in Firefox, the content field is being marked dirty when rich text editors (this happens with both Redactor and TinyMCE) are loaded. This is causing the form to think it has unsaved changes, which is triggering the navigation warning. I've not yet figured out why the field is getting marked dirty by the RTEs, but I'm working on it.

            Edit for clarity: This is related to the 2.2.11 bug in Firefox ONLY. Older versions of MODX have the known bug in Chrome 30 ONLY that has been solved in 2.2.11 where ANY page navigation away from the resource update panel would trigger a popup. This was fixed by removing the line indicated in this pull request (line 46). There's too many different issues being thrown around in this thread, so PLEASE be verbose about your MODX version and browser! [ed. note: markh last edited this post 10 years, 3 months ago.]
              Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

              Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
            • Progress!

              The problem is the difference between what the textarea returns as value, and what was the starting value. When using a RTE like TinyMCE or Redactor, there is always some code cleaning going on, enforcing root elements etc. After some serious core-extjs digging, I can reliably reproduce this in both Chrome and Firefox (both latest) in MODX 2.2.11.

              I have been testing on three random resources. The problem only occurred on two. The first one had this as content:
              <p>[[!Login? &preHooks=`preHook.DiscussLogin` &postHooks=`postHook.DiscussLogin` &loginTpl=`lgnTplMODX`]]</p>

              In that case, the dirty checking by the ExtJS core would load the value of the textarea after the RTE was initiated, which suddenly had encoded ampersands, like such:
              <p>[[!Login? &preHooks=`preHook.DiscussLogin` &postHooks=`postHook.DiscussLogin` &loginTpl=`lgnTplMODX`]]</p> 

              In this case, the dirty form check saw two different values, the field was marked dirty, and the navigation confirmation was shown.

              The second resource only had this as content:
              <p>You will update your profile here.</p>

              The RTE did not do anything with this. Content stayed the same, field was not marked dirty, no navigation confirmation as expected.

              The third one had me puzzled for a moment, but its content was
              Register here.

              and the RTE turned it into
              <p>Register here.</p>

              which was different -> marked dirty -> navigation confirmation.

              So that's the problem. I'm not sure why this initially seemed to be limited to Firefox (I can reproduce the above consistently across both FF and Chrome, both on Mac) but I'm guessing different resources were used in testing.. different content, as illustrated, will have different results. This may also be why Jason could not reproduce it, as I bet he doesn't use a RTE wink

              I'm now working on a patch that checks for the navigation warning differently, which should be more reliable and not depend on weird side effects of RTEs like this. Spoiler: the same way the Save button is enabled or disabled.
                Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                • 28840
                • 46 Posts
                H me it happens also on newly created resources and probably because RTE tinyMCE automaticly adds
                <p></p>
                and is seen as dirty.
                • Pull request with patches sent, see description of the PR for details: https://github.com/modxcms/revolution/pull/820 I believe it should resolve the issues in this thread in 2.2.11

                  @sumoborac I just double checked and the behaviour for new resources is (with the above patch) as it should be. The scenarios I checked:
                  1. Nothing added to the new resource form, no warning on navigation
                  2. Type something in the title, warning pops up when you navigate without saving.
                  3. Type something, save resource, no popup during reload.
                    Mark Hamstra • Developer spending his days working on Premium Extras and a MODX Site Dashboard with the ability to remotely upgrade MODX and extras to make the MODX world a little better.

                    Tweet me @mark_hamstra, check my infrequent blog at markhamstra.com, my slightly more frequent ramblings at MODX.today or see code at Github.
                    • 24983
                    • 59 Posts
                    Quote from: markh at Jan 26, 2014, 11:01 AM

                    Yes, removing the intentionally added feature will indeed make it go away ~_~ That's not a fix.

                    I'm working on a fix that leaves the feature in place but gets rid of some things reported here. So far I've added a setting (confirm_navigation) that will allow you to disable it completely without hacking core files.

                    I also found the root cause of the popup showing up in Firefox (MODX 2.2.11). It seems that in Firefox, the content field is being marked dirty when rich text editors (this happens with both Redactor and TinyMCE) are loaded. This is causing the form to think it has unsaved changes, which is triggering the navigation warning. I've not yet figured out why the field is getting marked dirty by the RTEs, but I'm working on it.

                    Edit for clarity: This is related to the 2.2.11 bug in Firefox ONLY. Older versions of MODX have the known bug in Chrome 30 ONLY that has been solved in 2.2.11 where ANY page navigation away from the resource update panel would trigger a popup. This was fixed by removing the line indicated in this pull request (line 46). There's too many different issues being thrown around in this thread, so PLEASE be verbose about your MODX version and browser!

                    I know, but my client was complaining so I had to do a quick and dirty hack.

                    Anyways, thank you for working on this issue. smiley [ed. note: rich last edited this post 10 years, 3 months ago.]
                      • 52634
                      • 60 Posts
                      @Mark: maybe it is possible to pack your patch into a patch package? That would ease it to quick fix the problem reliably until a new patch release is out...