As reported by Dean B in http://groups.google.com/group/google-custom-search-results/browse_fr... you need to hit the back button twice (in Firefox) when using the default Linked CSE setup. He also discovered, as I just did, that turning off resizing, removed the extra page in the history ("var googleSearchResizeIframe = false;"). I also discovered that this problem isn't present in the standard/non-linked CSE - even if it seems to use the same Javascript! I'm very reluctant to take the road Dean B did, modifying my own copy of "show_afs_search.js". That breaks badly when Google decides to add some new stuff ..
So my question/request is: Why do you need to have an explicit page reload when resizing the iframe when using Linked CSE, but not in the standard CSE? Please fix this issue ASAP. AFAIK it only affects Firefox users (as noted by Dean B).
I also have noticed the behavior described, i.e., googleSearchResizeIframe seems to have no effect with a Linked CSE setup. Setting a div height around the search results snippet isn't a real solution, because the results area is never consistently the same height -- especially if your chosen ad placement is above/below the results. The problem seems to affect any browser.
> As reported by Dean B inhttp://groups.google.com/group/google-custom-search-results/browse_fr... > you need to hit the back button twice (in Firefox) when using the > default Linked CSE setup. He also discovered, as I just did, that > turning off resizing, removed the extra page in the history ("var > googleSearchResizeIframe = false;"). I also discovered that this > problem isn't present in the standard/non-linked CSE - even if it > seems to use the same Javascript! I'm very reluctant to take the road > Dean B did, modifying my own copy of "show_afs_search.js". That breaks > badly when Google decides to add some new stuff ..
> So my question/request is: Why do you need to have an explicit page > reload when resizing the iframe when using Linked CSE, but not in the > standard CSE? Please fix this issue ASAP. AFAIK it only affects > Firefox users (as noted by Dean B).
i'm experiencing the same problem using my CSE with firefox. i guess my first question is what is the difference between "linked" and "non- linked" CSE's? i assume mine is "linked" as i'm having the same problem using the browser's back button, but was curious what the difference was. and my next question is where do i put the code to turn off the resizing? i assume i just plug it into the results code?
so, i added the code, and while it works in principle, the amount of white space i'm getting at the bottom of ALL the pages is unacceptable. there's nothing in my stylesheet that i can see would make it do that...
PS! Where is the CSE team? I would like at least comment on what we can expect? If nothing will be fixed, we'll have to write our own solutions using the AJAX search API.
Maybe the Firefox team can be contacted so they can modify the browser code so that it works the same way as in Internet Explorer for the future versions of Firefox?
Thanks for reporting this issue, it looks like a bug having to do with URL escaping. Your http header trace of the request showed the culprit; the requests should have identical paths, but you can see from these URL snippets that [ ~ ] is escaped in the first one as [ %7E ] but isn't in the second one:
While we working on getting this fixed, you can try using paths that don't contain a tilde. Sorry about the inconvenience - it's not ideal, but it should allow you to work around this problem until we have another solution.
perhaps i'm not completely understanding what you're saying, but i don't use any tildes in my directory paths and i'm having the same problems: http://www.boyleberrier.com/indextest.htm (i have now removed the extra code that was preventing the page reload)
> Thanks for reporting this issue, it looks like a bug having to do with > URL escaping. Your http header trace of the request showed the > culprit; the requests should have identical paths, but you can see > from these URL snippets that [ ~ ] is escaped in the first one as > [ %7E ] but isn't in the second one:
> While we working on getting this fixed, you can try using paths that > don't contain a tilde. Sorry about the inconvenience - it's not ideal, > but it should allow you to work around this problem until we have > another solution.
i was just messing around with it some more and have noticed strange things that seem to indicate there is a problem beyond the pages simply reloading:
at http://www.boyleberrier.com/indextest.htm if i search for "smith", it takes me to the results page and it takes two clicks to get back. if i do the search, then advance to the second page of results, i have to hit the back button three or four times to get a response, at which point it skips and takes me all the way back to the search page. if i then try the forward button, it will only go forward one page, to the FIRST results page. it exhibits a similar behavior if i advance to the second results page, click on a results link, then try to go back to the results: it goes back the first results page instead of the second.
> perhaps i'm not completely understanding what you're saying, but i > don't use any tildes in my directory paths and i'm having the same > problems:http://www.boyleberrier.com/indextest.htm > (i have now removed the extra code that was preventing the page > reload)
> On Aug 17, 2:03 pm, Custom Search Guide wrote:
> > Hi all,
> > Thanks for reporting this issue, it looks like a bug having to do with > > URL escaping. Your http header trace of the request showed the > > culprit; the requests should have identical paths, but you can see > > from these URL snippets that [ ~ ] is escaped in the first one as > > [ %7E ] but isn't in the second one:
> > While we working on getting this fixed, you can try using paths that > > don't contain a tilde. Sorry about the inconvenience - it's not ideal, > > but it should allow you to work around this problem until we have > > another solution.
Sorry for the confusion - the refresh error can be caused by characters other than the tilde. My fault for not making that clear. We're still working on this.
The other issue you're describing has come up before in the Group, and it's something that only occurs with certain CSE configurations, which makes it tricky to pinpoint and solve. For more details, you can review the following thread:
