After updating to 44 I noticed that the code for my email contact no longer functioned properly. After a bit of testing I decided to remove the div ID- swipe and the code functioned as before. The quick & simple solution for me is to remove that div ID on each of my sites until I figure out newer/better code for the email contact. I did want to let you know this was going on in case it affects other things I'm not aware of.

Here's the link: http://www.zrwon.com/index.html Click the Info icon (upper left) that takes you to the page "About the Website". You should be able to enter data in the three fields below "Questions or Comments" which is the way this page worked prior to the latest update. Leave at least one field blank and click the "click to send" button at the bottom and you should see the same page with "All Fields Required" in red (this is my error trapping when any field is left blank). Now try to enter data in any of the fields. Can't do it. I removed the div-swipe in the first file but left it intact in the second file.

I'll be interested in hearing what you think plus suggestions on a more permanent fix that might involve my updating the coding for that particular section. That set of code is kind like an old fashioned wedding ... something borrowed, something old.

FWIW, everything else really seems to work quite well. I really do like how Gromit has evolved into an incredibly powerful skin for photographers. Thanks.

OK - after further testing/checking I discovered that one of my 4 websites still works OK after the upgrade to 44 but still using the "old" code for email contact. I thought I was using the exact same code in each of the sites but apparently there is a little quirk I'm missing. And no, I haven't spent enough time analyzing the code to see why one works and one doesn't. I suspect that may be that I'm using a top menu in the site that functions OK since the div-swipe occurs earlier in the coding.

Here's the link: http://www.jret.net/index.html On the Menu bar click Info and you will see a similar page that I'm using on each of the other sites. Entering data in the fields is not a problem here. Color me confused until I have time to analyze more closely. btw, I'm using the same error trapping here as on the others. For grins, complete the 3 fields and hit send for an Easter egg.

Any hints as to where I'm going wrong? I realize this isn't your code (which almost always works without fail) but I would like to have a reasonably "safe" method for visitors to send me an email without me displaying my email address for all the robots to see.

In the jret.net site the full screen slide show on the home page is borrowed code that displays 6 slides. I enhanced it a little further so that it changes the 6 slides every hour, so visitors will see a different show depending on when they visit ... or they can use the menu & go directly to the content. I suppose the slide show is mostly for me but I have a few photographer friends who seem to enjoy it.

The jret.net website is totally generated from jAlbum & Gromit, thanks to the ability to add additional code in Gromit. This is a huge advantage when one wants to have a custom website for photos.

Your page where it's still working, where there's a page that has only the contact form on it, was constructed using the regular Gromit thumbnail page. On that, the swipe area applies only to the thumbnail table, and the way you've adapted the page, there is no thumbnail table. In short, that's not a swipable page at all.

On the "real" info page, the swipable area is the entire box of text, including the contact form. Why that fails to work after a page refresh, I have no idea. I'll keep poking at it.

But your concern about robots harvesting your email address is probably misplaced. Spammers don't bother with doing that these days. They can get millions of email addresses for small amounts of money from hackers who have harvested them directly from places like businesses that keep lists of email contacts. Scraping through individual sites, just to get single email addresses, isn't worth the effort.

I have some contact addresses posted in clear text online, and those addresses get virtually no spam at all.

First thing: Your info page material isn't valid HTML. There are some unmatched <div>'s in there. View the source code of the page in Firefox, and you'll see some red! That might be what's kicking it.

Once you've fixed that, if it's still misbehaving, here's a little experiment that might cure the info page contact form. In your code for that form, wrap the contact forum in another div using the noSwipe class:

First, you have me re-thinking "protecting" the email address. If robo harvesting is not a real problem then it would greatly simplify the page and probably solve the swiping issue.

I'll double check for unmatched <div>'s and see if that improves things. But if I've "disabled" the swipe feature using this code I imagine that I will discard the code & go much simpler. I've checked other pages on my Android and the swipe seems to work OK - but I never did check the swipe on the contact page.

One interesting observation.... On that info page, swiping doesn't work the first time you land on the page. If you enter incomplete info, and get the red warning about it, swiping works, but the form doesn't.

I have no explanation for this. I just offer it as an interesting symptom!

Bingo! This discrepancy is what has me scratching my head and why I posted. I will continue to study it but going back to a simpler, one-click for the email might be the best way. Although I remember a couple years back when I was using the actual email on the contact page, someone contacted me and complained that clicking the link didn't do anything and they had to copy/paste the address. Subsequent communications brought to light that they didn't use any email client but rather from logging into their email service (i.e. gmail, yahoo mail, or similar). Although that was probably an isolated incident it caused me to rethink the contact bit and look for some code that might work. I tried to replicate what the party described happening but was never able to, mostly since each of my computers has a default email client.

BTW, if you just want to disable swiping completely on that page, don't delete the <div> - that's where you start getting into trouble with unmatched tags. Instead, just remove the ID from it:

Change:
<div id="gr-swipe">
To:
<div>

And yes, a clickable mailto link is a problem for users that don't use an email client program. I've seen some godawful workarounds, but as long as you keep the actual email address visible, those users aren't shut out. They can either right-click and choose "Copy email address" (Chrome and Firefox - Edge screws it up by including the mailto label in the copied text), then paste the address into their webmail, or just look at the address and enter it in their webmail interface manually.

OK - the HTML is now valid. Not sure what I did wrong but probably created the error through manual tinkering. Anyway, I used jAlbum to create the main page + infopage.

I added the noSwipe class before the form and closed it after the form closed. The page created is infopage.html. It checked out OK at the W3C Validation site. The second info page with the red text is essentially the same as the main infopage except that I manually added a div class='red' and renamed the copy to infopage.htm. Not sure if that naming is a good practice but seems to work OK in the browsers I've tested it on.

Both pages work with my browsers altho I haven't tested in on my Android yet. I assume that the form cannot be swiped. I also added the html mailto: link to my name which now appears in blue txt & red txt when hovered over. This works fine on my computers but I doubt that it will be user friendly for anyone without an email client. The simple mail link is actually a cleaner solution and uses much less space than the form - the kicker is when a user tries to email without an installed email client.

The mystery continues - I rebuilt the home page w/info page of a different site that essentially functions the same as the one we've been working on. I did NOT add the noSwipe class.

I copied the info page, edited the div=red command, and saved as an .htm file then uploaded the files including the res folder and checked the html at w3.org - no errors. The form does not work on the first info page but does work on the second info page. I did not check swiping on an Android. Ideas?

The new "first info page" appears to work just fine in a desktop browser, and on Android. On a desktop, if you don't enter all the info, and get the warning, you can still enter text in the form.

As expected, swiping works up in the text area, but not over the form itself. This is exactly what the script should do.

Edit: You probably need to do some cache-clearing while you're testing all of this, especially on your phone. Phone browsers can be very stubborn about hanging on to cached versions of pages.

EditEdit: The Tuband page works fine on Android, but not on desktop. I believe that adding the noSwipe class will make it behave, though there won't be much of swipable area left. So, probably best to eliminate swiping entirely on that page by removing id="gr-swipe".