The number of items in cursor.pages[] is sometimes incorrect.

[GoogleCodeExporter]

The number of items in cursor.pages[] is sometimes incorrect.

* This appears to happen when Google omits similar entries for a query
(i.e. there are more search results, but Google only shows the most
relevant ones). It can be recreated by going to the Raw Searchers Demo at
www.google.com/uds/samples/apidocs/raw-searchers.html and entering
something like: "site:tropicana.com peach". It comes up with 4 page links
at the bottom, even though there are only 2. When you click on any of the
page links other than 1, links number 3 and 4 disappear. If you go to the
first page of results, they reappear.

* This is platform and browser independent. 

Original issue reported on code.google.com by lisba...@gmail.com on 1 May 2008 at 6:10

[GoogleCodeExporter]

Is that relevant to this as well:

Do an advanced search on Japanese pages for 青 like this:
http://www.google.com/search?hl=en&as_q=%E9%9D%92&as_epq=&as_oq=&as_eq=&num=10&l
r=lang_ja&as_filetype=&ft=i&as_sitesearch=&as_qdr=all&as_rights=&as_occt=any&cr=
&as_nlo=&as_nhi=&safe=off

Next through the API (normally with key):
http://ajax.googleapis.com/ajax/services/search/web?v=1.0&lr=lang_ja&q=%E9%9D%92

Normal search shows: Results 1 - 10 of about 838,000 Japanese pages for 青
API search shows: "236000" for the cursor.estimatedResultCount

A 600000 results difference is a bit odd.

Original comment by asheme...@gmail.com on 1 Jun 2008 at 8:36

[GoogleCodeExporter]

Original comment by internal...@gmail.com on 3 Jun 2008 at 5:51

• Added labels: APIType-Search

[GoogleCodeExporter]

This problem has been unresolved for 3 months, is anyone actually working on 
this ?!

Original comment by brami...@gmail.com on 28 Jul 2008 at 8:27

[GoogleCodeExporter]

Would like to see this resolved too. I'm using the API from PHP via JSON and 
this is
a bit embarrasing because because the client thinks it's my error.

Original comment by johnpitc...@gmail.com on 30 Jul 2008 at 3:10

[GoogleCodeExporter]

This and Defect 32 seem to be the same thing. For my issues see Defect 32.

Original comment by a_star_c...@hotmail.com on 27 Aug 2008 at 5:48

[GoogleCodeExporter]

Issue 158 has been merged into this issue.

Original comment by jrgeer...@gmail.com on 27 Nov 2008 at 2:13

[GoogleCodeExporter]

This problem has been unresolved for 10 months, is anyone actually working on 
this ?!

Original comment by fensterm...@gmail.com on 5 Mar 2009 at 9:09

[GoogleCodeExporter]

This happens because the number of pages relies on the estimated result count, 
which is inherently inaccurate 
because it is only an estimate.  This is by design and there are currently no 
plans to change it.

Apologies for any inconvenience.

Original comment by lisba...@google.com on 5 Mar 2009 at 9:15

[GoogleCodeExporter]

This is so ridiculous! I can't believe Google has no plan to fix this issue. If 
that
is your design model for this application it should seriously be reconsidered. 
Why
not verify that each result page in the pagination result set will contain data
before setting the value of cursor.pages.length? Is there a work around for this
issue or anything? It makes sites that use this technology look poorly designed.

Original comment by andek...@gmail.com on 30 Apr 2009 at 7:47

[GoogleCodeExporter]

I'm not entirely sure, but the problem I am running into may be related to this:
http://groups.google.com/group/Google-AJAX-Search-API/browse_thread/thread/93691
75170287418#

It practically renders any information carried by the result cursor useless. 
For me,
it just happens on the first page though: Say the cursor reports 100 results, 
and 4
pages of result data with 8 results each, then the first page may sometimes 
contain
only 2 results, while the following pages are fully populated with 8 results...

This breaks any pagination in the UI and one must resort to hacks to fix this 
(e.g.
dispatching the first query twice should the result data be incomplete).

This is indeed a major issue, please fix this ASAP!

Original comment by m.kaepp...@gmail.com on 4 May 2009 at 12:00

[GoogleCodeExporter]

Working on more accurate estimates would really be helpful.  It's very 
disconcerting
when pages don't exist!

Original comment by searchto...@gmail.com on 19 Jun 2009 at 9:28

[GoogleCodeExporter]

I have to agree with  "fenstermakera" this issue is so big it kinda makes the
websearch API useless. I mean no one wants their website to look as 
unprofessional as
to claim that there are 4 pages of results when there are actually only 2. I've 
been
hacking at this thing for days and can't come up with a work around, which has 
lead
me to genuinely consider switching to yahoo's API, which bums me out, because 
google
rocks. I've always said I look forward to the day when I find something about 
google
I don't like... but I take it back, I want this API to work. :-(

Original comment by Lamba...@gmail.com on 22 Jun 2009 at 10:05

[GoogleCodeExporter]

I also agree this needs to be fixed. I thought there was a problem with my code 
or
something I did wrong. Then I noticed when I copied the basic code from the CSE 
Code
section, it provided 8 pages in the bottom, however not all results had 8 
actual page
results. So you would click on page 8 but it would instead put you on Page 4 and
there were no further numbered pages....

This is an issue that needs to get resolved please. Since the javascript API 
limits
the  result set to 64... why not then do a count of the results up to 64? If  it
exceeds 64 then stop the count, if it's lower (which is the issue for us) then 
set
the proper and accurate number of the counter. Having proper pagination is 
important.

Original comment by leggetts...@gmail.com on 24 Jul 2009 at 4:06

[GoogleCodeExporter]

same problem with french version of the API. Can it be resolved ? that's really
annoying for users.

Original comment by jerome.g...@gmail.com on 30 Nov 2009 at 11:49

[GoogleCodeExporter]

how you managed to parse and present google search api result pages in php ? 
...in
order to display 1, 2, ...>next pages ?
thx

Original comment by shmeker...@gmail.com on 21 May 2010 at 11:29

[GoogleCodeExporter]

Also having this issue would love it to get fixed...

Original comment by loweg...@gmail.com on 15 Jul 2010 at 3:01

[GoogleCodeExporter]

Hi folks.  I may have a simple workaround for some of you.  NOTE:  This 
workaround is highly implementation specific.

In my implementation I effectively have one <div> per result returned.  All of 
my results are contained within one parent <div>.  So if I set 
gLocalSearch.setResultSetSize(8) then I will normally have 8 result children 
<div>'s within my one parent <div> per each page my user's cycle through.  It 
should look something like this.  For simplicity I am making this pretty bare 
bones.
<div id="parent">
  <div class="resultChild"/>
  <div class="resultChild"/>
  <div class="resultChild"/>
  <div class="resultChild"/>
  <div class="resultChild"/>
  <div class="resultChild"/>
  <div class="resultChild"/>
  <div class="resultChild"/>
</div>

Now, in the case that the pages.length is off as explained above (and in my own 
issue as well) I end up less than 8 result children.  In my example I am only 
on page 2 of 4 so I expect I have 2 more pages coming, but lo and behold I only 
have 2 result children.
<div id="parent">
  <div class="resultChild"/>
  <div class="resultChild"/>
</div>

So I added in a check that also counts the number of result children and 
compares that to the value used in gLocalSearch.setResultSetSize() which in my 
case is 8.
Here is an example of how I did this using jQuery.
var resultReturned = jQuery("#parent > .resultChild").size();

Then
var resultSize = gLocalSearch.getResultSetSize();

Finally
if resultReturned < resultSize then I know I have a case where I will override 
what pages.length is telling me.

This is not what I would call optimal, but given the circumstances this was a 
simple solution that works well for me.  Hopefully it might help out one of you.

Take care :)

Original comment by Sonic...@gmail.com on 16 Sep 2010 at 5:20

[GoogleCodeExporter]

One fix that's seems to be working for me, it to make additional requests. 

The problems allways seems to be that early pages show that there are to many 
additional pages - the later pages show the "correct" number, or at least the 
smallest number of pages.

First you make the request with start=0.

Then find out how many pages there are, make a request with start set to that 
number of pages and check how many pages there area now.

Save the new totalpages gotten with that latest request, and make now write 
your pagination.

This is by no means a perfect solution, and it requires an additionl request, 
but atleast it sidesteps the problem with pagination changing with every page.

Original comment by s...@bluerange.se on 18 Oct 2010 at 7:50

[GoogleCodeExporter]

The number of items in cursor pages is based on the Estimated Results Count.  
As described in issue #32, this estimate is not always correct.  For most 
queries, it's not a problem.  However, for queries with only a couple pages, 
the cursor might be unreliable.  Unfortunately, this is a facet of how the 
pages[] are calculated and cannot be fixed.

Original comment by adam.fel...@gtempaccount.com on 10 Nov 2010 at 10:43

• Changed state: WontFix

[GoogleCodeExporter]

Original comment by adam.fel...@gtempaccount.com on 13 Nov 2010 at 2:21

• Added labels: Restrict-AddIssueComment-Commit