Can you post a link to an example that replicates the described behavior?

Thanks!

(No comment was entered for this change.)

http://www.polyarc.us/aspect

I can work around it with "clientWidth" & "clientHeight" for the container DIV

Okay, I've reported this as confusing behavior. Do you recall if v2 gave the same 
results?

Sorry, I don't know what V2 did.  I am no longer using it.  I have found a "work
around" for V3 which I like except for the totally useless hidden static map I cannot
disable.  Pamela, please use your influence to make the hidden static map optional. 
Adding an extra 160KB non-cacheable file to every pan & to every zoom is outrageous.

(No comment was entered for this change.)

(No comment was entered for this change.)

Bratliff reports that this is still not fixed for zoom levels 0 and 1.

(No comment was entered for this change.)

Bratliff, can you verify this is now fixed?

Still not working with zoom levels 0 and 1, as reported by bratliff.

Test page:
http://www.provide.net/~bratliff/issue/

(No comment was entered for this change.)

Bratliff, do you still have the example to replicate this:
http://www.provide.net/~bratliff/issue/

Looks like you may have taken it down since there hasn't been any updates in a while.
 If you still have it, can you please repost it?  Otherwise, I'll mock up a new
example to verify whether this has been fixed.

A LatLngBounds can represent at most 1 longitudinal copy of the world: after this point it is "full".  When more than 1 copy of the world is in view, the LatLngBounds becomes full, so the conversion from pixels to longitude is not invertible.

would it be out of the question to at least ask for some helpful way indicate that the 'world is wrapping'? 
I dont think it should be too much to ask for, since the current bounding system is broken & almost useless at low zoom levels...

How about providing a collection of 'LatLngBounds' objects that fully cover the visible map? 

example:
a 1360px-wide map@zoom level '1' will wrap approx. 1.5 times.
For this example, let's say that the map spans from '117 longitude' all the way to '-18 longitude' by doing one full wrap...

In this case, the api's 'map.getBounds()' method could return an array of valid 'LatLngBounds' objects, instead of returning 1 single 'distorted' bounds object...

At higher zoom levels, where the map would only be spanned by *one* LatLngBounds valid LatLngBounds object, a single element array would be returned...Anytime there's a crossing of the dateline, a two (or more) element would be returned.

The programming logic would be something like the following:
var b=map.getBounds();
if (b.length==1){
  //process single bounds object
}else{
   for(i=0;i<b.length;i++){
      //process each bounds object
   }
}

So, in the above example, 'getBounds()' would create an array with 3 elements:
bounds[0]: LatLngBounds object with lng values spanning 117 => 180
bounds[1]: LatLngBounds object with lng values spanning -180 => 180
bounds[2]: LatLngBounds object with lng values spanning -180 => -18

obviously, bounds[0] and bounds[2] are seemingly 'superfluous,' since bounds[1] is 'full world' and covers all 3 of the spans in the array...however, its still logically & programatically more 'correct' to return the actual valid 'LatLngBounds' objects that exist within the visible map. This way, the api user is able to filter&process the available LatLngBounds objects in a much clearer and more direct way, by easily determining which bounds objects are needed and which can be discarded ... 

in a sense, this same logic can (and possibly *should*?) be applied to any api function(s) that must translate LatLng-based values into pixel space and vice-versa (example: On a wrapped map, the 'fromLatLngToDivPixel' function should return array of 'Point' objects instead of a single 'Point' object, since a wrapped map would actually contain more than one pixel 'Point' per 'LatLng' value). 
However, a problem that I could forsee is 'how to determine which 'LatLng-to-Point' must be used? for example, when generating a tooltip on a map marker; which pixel point should be used for a given 'LatLng' value? a single one? or all available Points? Perhaps the visble map's 'LatLngBounds' objects can again be used to help 'uniquely identify' a 'LatLng=>Point' pairing... i.e., something like "i need the pixel 'Point' object that is mapped to a given 'LatLng' object within the map's first available 'LatLngBounds,' i.e. 'bounds[0]'".

perhaps all of this seems like a drastic set of changes, but it looks like a more logical solution, especially if google is going to insist on offering an API that allows for 'wrappable' maps.

any thoughts/feedback?

a couple of corrections:
1) the above example actually consisted of '2.5' wraps, so the bounds array would instead be a 4 element array:
bounds[0]: LatLngBounds object with lng values spanning 117 => 180
bounds[1]: LatLngBounds object with lng values spanning -180 => 180
bounds[2]: LatLngBounds object with lng values spanning -180 => 180
bounds[3]: LatLngBounds object with lng values spanning -180 => -18

2) I forgot to mention in above proposal is that this 'multi-bounding' functionality should somehow be internally 'tied' to the pixel space in order to uniquely identify 'where the bounds exists' on the visible map.
So, in the above example:
bounds[0] would be tied to pixel space '0 => ~90' pixels in x-direction
bounds[1] would be tied to pixel space '~90 => ~600' pixels in x-direction
bounds[2] would be tied to pixel space '~600 => ~1115' pixels in x-direction
bounds[3] would be tied to pixel space '~1115=> ~1360' pixels in x-direction
* the above pixel x-direction values are approximate of course...

anyway, this would then allow for mapping a LatLng=>Point value (or vice-versa) within a specific 'bounds' of the visible map.

again, thoughts/feedback welcome...

(No comment was entered for this change.)