Invalid warning about changed content about mercury

[JeanMertz]

After some more investigating I think I've found part of the solution.

Say we have this inside an editable region:

<p>
  Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
</p>

This is how it shows up in the Google Chrome Web Inspector Panel:

Now, when I click with the mouse after the first sentence, the inspector suddenly shows this:

Obviously, nothing has changed in the actual html layout, but the web inspector shows a different layout. I suspect this is because of the <em> markers that get placed (and immediately removed) by Mercury at the start and end of a selection. You can even see this in the inspector where an element is added and removed in a flash.

So after clicking even once in an editable region, Mercury falsely detects changes and shows a confirm box before leaving the page.

This also happens when the page is first loaded, without any (clicking) action being triggered by the user. But it doesn't happen every single time in this case. So I think this has something to do with Mercury focussing the first element in a specific way IF the element couldn't be focussed in the default browser way (I think I read something about this in the code or the readme). So in this situation, it happens, not not every time.

I also can't see any changes in the inspector in this situation, but I suspect this is because it happens immediately when the page is loaded, and no change is visible because the cursor is actually placed at the start of the region, so no splitting of lines is taking place in the inspector.

[jejacks0n]

You're right about most of this stuff, and it's impressive that you remember all of these details.. Yeah, the placing of the selection element totally breaks any "text" nodes, which is tremendously annoying -- it limits some of the things that are possible -- like placing the cursor in a word and wrapping that whole word in bold when you click the bold button (because it's now in two text nodes, which makes it way more complicated than it needs to be).. I'll eventually get around to refactoring all of that to use a better selection object -- if possible.. but I digress.

Mercury doesn't prompt when leaving unless it thinks there are changes.. there's a lot of things that tell mercury that changes have been made, and at some point that must be happening when no changes are made.. this has actually been on my list for a while, so I'll try and get to it today.

[jejacks0n]

So the only way I could get this to happen is by hitting meta+r to refresh the page.. navigating around was fine for me -- so you may have something that's breaking it (calling region.execCommand or something), or you could be seeing what I'm seeing and just mis-interpreting it like I did.

I've made some adjustments to how the changes are tracked, and moved them to keyup instead of keydown.. that way the browser will do it's thing on keydown, and on keyup, if the browser hasn't done anything like refreshed the page we'll assume changes were made.

Hope that solves your issue, but I'm curious if you were just seeing what I was seeing as well as it seems likely.

[JeanMertz]

Well, what I was seeing was a notification from mercury before page unload (either through a refresh or clicking a link on the page (outside editable regions). The notice always showed in this situation if I had clicked inside an editable region before navigating away and it would sometimes show when not doing anything on the page at all, simply navigating to the page and then navigating away right away triggered the warning.

I haven't tested this last scenario to the full extend yet, so I will do that when I get back to my workstation on Monday, and will see if your changes solved things.