Now with SoftPress2 back online, hopefully we can see a little more life in this forum!
I’ve been making some changes to my Freeway site with regard to my Search field. I’ve got something I like, which works great in FireFox and IE and Chrome on Mac and Windows8, but for some reason it doesn’t work in Safari on Mac or Chrome on WinXP.
I’ve created a JS Fiddle here (with instructions):
Without that, it works in all browsers, but of course that is not what I want. What I want is for the user to type their search query then hit Return, and then when they return to the page (via Back Button, etc.), the search field will be blank and deselected. Using that “reset” bit works to achieve my aims, but stupid Safari doesn’t like it. Would any of you know why, and how to fix?
Thank you,
James Wages
dynamo mailing list
email@hidden
Update your subscriptions at:
Now with SoftPress2 back online, hopefully we can see a little more life in this forum!
I’ve been making some changes to my Freeway site with regard to my Search field. I’ve got something I like, which works great in FireFox and IE and Chrome on Mac and Windows8, but for some reason it doesn’t work in Safari on Mac or Chrome on WinXP.
I’ve created a JS Fiddle here (with instructions):
Without that, it works in all browsers, but of course that is not what I want. What I want is for the user to type their search query then hit Return, and then when they return to the page (via Back Button, etc.), the search field will be blank and deselected. Using that “reset” bit works to achieve my aims, but stupid Safari doesn’t like it. Would any of you know why, and how to fix?
Thanks for the tip, David. I never noticed that on the English site because I spend most of my time on the Japanese site which doesn’t have that problem at all:
Thanks again, David. There was a little HTML box on the page named PlaceHolder that should not have been on the page, and that was causing the narrow-browser-window problem. It’s now fixed.
James
dynamo mailing list
email@hidden
Update your subscriptions at:
Folks, I’m here on my knees pleading for the coders among us to kindly offer me a little guidance on the “this.reset();” problem I mentioned in my opening post.
Surely there must be a solution. I’ve spent several hours on my own trying to find a solution, but that time was in vain. That is why I posted here.
Any ideas at all would be greatly appreciated!
Thank you,
James Wages
dynamo mailing list
email@hidden
Update your subscriptions at:
You generally cannot do anything to a page after you submit a form contained within it.
What is your goal here? Because what you’ve written in the onsubmit appears to me to be contradictory. If you want to submit the form, it has to have content in it. If you reset it, it will lose its content and that may happen before the form sends to the server.
Is there a specific goal you have in mind here? Try instead of coding, writing in prose what you want the page to do when a user 1) First encounters the page, 2) Fills in the search form, 3) Submits the search form, etc.
If I didn’t know better, I could swear you were looking to have the form submit while remaining on the current page. If that’s the case, then just make an Ajax request to the server, and update another element on the page with the results.
Walter
On Feb 24, 2017, at 2:05 AM, JDW email@hidden wrote:
Now with SoftPress2 back online, hopefully we can see a little more life in this forum!
I’ve been making some changes to my Freeway site with regard to my Search field. I’ve got something I like, which works great in FireFox and IE and Chrome on Mac and Windows8, but for some reason it doesn’t work in Safari on Mac or Chrome on WinXP.
I’ve created a JS Fiddle here (with instructions):
Without that, it works in all browsers, but of course that is not what I want. What I want is for the user to type their search query then hit Return, and then when they return to the page (via Back Button, etc.), the search field will be blank and deselected. Using that “reset” bit works to achieve my aims, but stupid Safari doesn’t like it. Would any of you know why, and how to fix?
Walter, because I have Freeway’s “Form Setup” dialog filled out appropriately, I do not need any JavaScript to get the form to submit at all. The user need only type a keyword (for example, “alarm”) and then hit RETURN. That will submit the keyword “alarm” to Google and then the search results page will appear. That works fine. No edits required.
The problem is that when the user clicks the Back button or hits CMD-[ to go back to the search field page, the keyword they typed is stuck in that field. To me, that looks unsightly. I want that keyword removed and the search field to be restore to its pristine, untouched condition. That is the aim here.
I am able to accomplish my aim with the code I’ve linked for everyone to see, in my opening post. The problem is that Safari chokes on it for reasons unknown to me. Other browsers don’t choke on it, except for Chrome on Windows XP, but I don’t really care about XP – even so I mention it only because I tested it and found it chokes (even though FireFox does not). FireFox is happy with my code on any platform. And newer versions of IE on newer versions of Windows are happy too. Again, it is Safari that is the problem. But why? That is what I wish to know.
Any ideas?
Thanks,
James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
What I am trying to do is nothing unusual. I see it done everywhere. For example, check out the following StackOverflow page:
Click in the search field atop that page and type a keyword. When the search results appear, click the browser back button and take note that the keyword you typed is not there.
Here’s yet another example. Visit Apple’s website, click the magnifier, type a search term, then on the results page click the browser back button. Note that your keyword is NOT stuck inside a search field after you return to the page on which you initiated the search.
That’s all I want to achieve.
Again, any thoughts? My code mostly works to do what I want, I just don’t understand why Safari chokes on it.
Thanks,
James
dynamo mailing list
email@hidden
Update your subscriptions at:
I’m not sure the code you’ve entered here is doing much of anything for you, and it may be actively hurting your page. I tried filling out the form and pressing return, and Google returned no results. Not even a “sorry, didn’t find anything to match”, just a header and no body content in the bottom area. The thing is, what you’re trying to do is alter the page after it has been closed for writing by the browser. If other browsers let you do that, that’s their bug. Safari is doing the correct thing by locking the DOM when the form is submitted.
The back button draws from the browser’s history cache, and thus has a picture of the page as it was when you left it. That’s what it shows the visitor when she presses the back button. I remind you, this is the exact expected behavior of any form on any site. If you are using back to navigate, you get the page from the history, not the server.
What you might want to do is put a search form on the results page, and allow it to be filled in by the querystring, too. That way there is no ambiguity about what is going on here. People who want to clear that form will either select-and-delete manually, you could add a reset button on the results page, or you could add a different UX pattern like click-to-select if you’re allergic to extra elements.
This approach would not prevent the user from using that back button, but if they didn’t find what they were looking for on the first try, they could take another stab at it from the results page, without having to navigate anywhere.
Walter
On Feb 26, 2017, at 8:10 PM, JDW email@hidden wrote:
Walter, because I have Freeway’s “Form Setup” dialog filled out appropriately, I do not need any JavaScript to get the form to submit at all. The user need only type a keyword (for example, “alarm”) and then hit RETURN. That will submit the keyword “alarm” to Google and then the search results page will appear. That works fine. No edits required.
The problem is that when the user clicks the Back button or hits CMD-[ to go back to the search field page, the keyword they typed is stuck in that field. To me, that looks unsightly. I want that keyword removed and the search field to be restore to its pristine, untouched condition. That is the aim here.
I am able to accomplish my aim with the code I’ve linked for everyone to see, in my opening post. The problem is that Safari chokes on it for reasons unknown to me. Other browsers don’t choke on it, except for Chrome on Windows XP, but I don’t really care about XP – even so I mention it only because I tested it and found it chokes (even though FireFox does not). FireFox is happy with my code on any platform. And newer versions of IE on newer versions of Windows are happy too. Again, it is Safari that is the problem. But why? That is what I wish to know.
Like I said in my previous post. I am not seeking to do something new. StackOverflow does it. Apple.com does it. Countless other sites do it.
You put a search field on every page. The user types a keyword somewhere. They get a search results page. They then click the browser’s back button. After that, when they look at the search field, they don’t see their keyword stuck in that search field.
Go to Apple’s site and try it.
Try it on StackOverflow.
–James
dynamo mailing list
email@hidden
Update your subscriptions at:
Those sites could be setting a server header that causes the page to not be returned from cache on reload. You are creating a static page. The examples you are citing are heavy heavy server-side rendered Web applications. Not the same animal, and trying to ape what they look like without reproducing their tech stack is going to end in tears for you. What you are describing (and yes, I did look at the sites in question) is not normal, it is something quite refined that they have expended massive engineering resources to achieve. Make a static form in Freeway. Host it on a regular shared server somewhere. Visit it in a browser, and see what the back button does. That is what is normal.
In the case of Apple, there’s two things going on that mask the normal behavior from your sight. First, the search field is hidden on page load, because it only appears by a click handler (which is not stored in the history), second, the search field resets with an Ajax request to “suggestions”, which pre-fills the category names for the type-ahead search results and zeros out the field itself. That’s a POST request sent after the page loads (or reloads). I didn’t dig into SO in detail, but I imagine that they are doing something similar, because they also provide type-ahead search results.
The code you put in your onsubmit form attribute is like four shotguns being fired in four different directions, but on Safari, none of them are hitting the target, because the form is locked along with the rest of the DOM at the instant that you click the submit button.
If you are 100% convinced that you must fix this (and then I have failed you), then you can’t make this work without adding a submit button to the form. Observe the click event on that button, stop the event from propagating to the form, read the value from the search field into a variable, set the value to the empty string, then set the window.location.href to the form action + querystring (using the value you stashed a few steps back). That might work in Safari.
Walter
On Feb 26, 2017, at 8:34 PM, JDW email@hidden wrote:
Walter,
Like I said in my previous post. I am not seeking to do something new. StackOverflow does it. Apple.com does it. Countless other sites do it.
You put a search field on every page. The user types a keyword somewhere. They get a search results page. They then click the browser’s back button. After that, when they look at the search field, they don’t see their keyword stuck in that search field.
Go to Apple’s site and try it.
Try it on StackOverflow.
Walter, you have not failed me. Nevertheless, I don’t want any Submit buttons. To me, that is a bit retro. I like the “type and hit return” approach.
So I did more research and found I could leverage the browser cache to resolve the Safari problem, as per this page:
I edited my JavaScript and confirmed it is working in Edge on Win10, IE11 on Win8.1, Safari, Chrome (even Chrome 36 on WinXP), FF (even FF48 on XP), and iOS 10 & iOS8.1 via the iOS Simulator on my Mac.
Type “alarm” and hit return. Notice how the search results appear just fine. Then click the browser BACK button. Form gets reset perfectly! (No keywords stuck in the search field.)
–James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
I edited my JavaScript and confirmed it is working in Edge on Win10, IE11 on Win8.1, Safari, Chrome (even Chrome 36 on WinXP), FF (even FF48 on XP), and iOS 10 & iOS8.1 via the iOS Simulator on my Mac.
Type “alarm” and hit return. Notice how the search results appear just fine. Then click the browser BACK button. Form gets reset perfectly! (No keywords stuck in the search field.)
I’ve actually been checking my web pages with Google’s PageSpeed Insights lately and it complains about “render-blocking JavaScript” …
In my case that render-blocker is the Protaculous Action for Freeway, which uses the rather large Prototype framework (about 170k before gzipping), and it uses the slightly older 1.7.0.0 version instead of the latest 1.7.3 too.
I thought about a move to jQuery, but that too would be an external JS file that technically would be “render-blocking,” so I shifted over to putting pure JS on the page, despite the fact I am not well versed in that language.
Putting more on the page itself means I don’t get caching benefits, but it also means fewer server requests. I’m now trying to find the proper balance between server requests and the caching benefits of having external files.
Anyway, thank you for your kind assistance in this discussion!
Sincerely,
James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
I’ve discovered one caveat to my code. On pages in my Freeway site where I use the Rollover Action, I always choose “Preload: Yes” in the “Parameters” section (Actions palette). That results in the following HTML output:
<body onload="FWPreload()">
That conflicts with the JS I wrote (to defocus and clear my search field) due to the existence of 2 “onload” instructions:
//defocus search field and clear its contents under 2 conditions
window.onload = function(){
var GF = document.getElementById("Field");
//condition1: on page load
GF.value = "";
GF.blur();
//condition2: when user clicks outside field
GF.addEventListener("blur", function COF() {GF.value = '';});
}
Disabling “Preload” on all my Rollovers is a fix (that deletes the ‘onload’ in the ‘body’ tag), but there are two big problems with that:
It’s a lot of work.
Rollover images won’t show instantly, which I consider a problem.
And deleting ‘onload’ from my JS code isn’t an option either as that clears and defocuses the search field as I desire.
Would you know of any tricks to resolve this?
Thanks,
James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
I know I can solve the problem by simple edits in TextWrangler:
Delete ‘window.onload’ from my JS, and uniquely name my function.
Add that new function name in the body ‘onload’.
//clear & unselect search field on page load
function SFcleaner(){
var GF = document.getElementById("Field");
//delete field contents and defocus on page load
GF.value = "";
GF.blur();
//delete field contents and defocus when user clicks outside field
GF.addEventListener("blur", function COF() {GF.value = '';});
}
<body onload="FWPreload();SFcleaner();">
But the problem is that Freeway auto-creates the “FWPreload()” in the body tag when needed. I cannot manually edit all my pages every time the site is rebuilt in Freeway.
I would appreciate hearing your thoughts.
Thanks!
James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
Yes. You don’t want to use or set body.onload, for just this reason. You want to use document.addEventListener('load',function(evt){ ... your function here ... }); instead. That’s because you can stack multiple listeners on a single event, and adding one does not delete another. They work the same way, and they don’t get in each other’s way.
Walter
On Mar 1, 2017, at 3:08 AM, JDW email@hidden wrote:
Altering the code as you suggest certainly resolves the dual-onload conflict, but it creates a new problem too. Here’s my modified code, as per your advice:
//clear & unselect search field on page load
document.addEventListener('load',function(evt){
var GF = document.getElementById("Field");
//delete field contents and defocus on page load
GF.value = "";
GF.blur();
//delete field contents and defocus when user clicks outside field
GF.addEventListener("blur", function COF() {GF.value = '';});
}
The problem that results is that the closing line in the code above no longer works to clear the contents of the field when the user clicks outside the field. In other words…
This part of the code still works fine…
GF.value = "";
GF.blur();
But this line no longer works at all…
GF.addEventListener("blur", function COF() {GF.value = '';});
I tried moving that last line outside the function, as follows, but it still doesn’t clear the field contents when the user clicks outside the field:
//clear & unselect search field on page load
document.addEventListener("load",function(evt){
var GF = document.getElementById("Field");
//delete field contents and defocus on page load
GF.value = "";
GF.blur();
});
//delete field contents and defocus when user clicks outside field
document.getElementById("Field").addEventListener("blur", function(evt){
document.getElementById("Field").value = '';
});
I tried this variation, but it does not work either…
//delete field contents and defocus when user clicks outside field
document.addEventListener("blur", function(evt){
document.getElementById("Field").value = '';
});
Changing “document” to “window” does not resolve the problem either. Before, when I used “window.onload” it worked fine to clear the field contents when the user clicked outside the field.
Any idea what I am missing?
Thanks,
James W.
dynamo mailing list
email@hidden
Update your subscriptions at:
//delete field contents and defocus when user clicks outside field
function blurMe(evt){
if (evt){
document.getElementById("Field").value = '';
}
}
window.addEventListener("blur", blurMe, false);
James W.
dynamo mailing list
email@hidden
Update your subscriptions at: