Closed Bug 669887 Opened 13 years ago Closed 13 years ago

Firefox 5.0 & google map infowindow content problem

Categories

(Core :: DOM: Core & HTML, defect)

5 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 591718

People

(Reporter: bataboske, Unassigned)

References

Details

(Keywords: qawanted)

After populating google map infowindow with html content (with jquey ajax), everything is shown correctly.
But when trying to open select dropdown inside infowindow, options are shown above the map_canvas.
Same happens with jquery calendar plugin that is rendered above the map.

I can confirm that the problem first occurred in FF4. 

FF3.x, IE8, IE7 & IE6 are showing content correctly.

Note:
I'm testing it on facebook application http://apps.facebook.com/locmein (Set Location -> Save)
Component: Build Config → DOM
Product: Firefox → Core
QA Contact: build.config → general
Version: unspecified → 5 Branch
This bug really needs a way to reproduce.  Ideally a link to the page that shows the problem.
Well, I already gave it
http://apps.facebook.com/locmein

It's facebook application though, but if you select "Set Location" and than "Save" it will show infowindow with html form and select list.
That requires a facebook login, which I don't have.
I'm really sorry to hear that.
I hope facebook will lower fee for new accounts.
That fee being "give up your personal information to Facebook"?  Yes, I do too.  I don't expect it to be lowered.
C'mon man. This is 21 century. 
Make some dummy account on gmail or yahoo and use it on facebook.
If you want I can make you one for testing...
> If you want I can make you one for testing...

For for it!  If you can do that and give me steps to reproduce that someone who has never used facebook could follow (on the level of "click the link that says 'X', then click the button that says 'Y'), that would be very useful in getting somewhere on this bug.
Ok.
Step by step.

Go to www.facebook.com and login with 
email: fbapptst@yahoo.com
passwd: fb.app.tst

After you log in to facebook, type in the address bar
http://apps.facebook.com/locmein
It will open facebook application LocMeIn
Click on the link "Set location" (in the header bellow like button).
Marker will be placed on the map and in infowindow you'll see "Save location" link.
When clicking on "Save location" new infowindow will open with html form.
There's select dropdown at the middle (Location type). 
Click on it and you'll see that options are rendered above the map.
Also, you can click on date textbox and see calendar on the wrong position.

Now, I hope you'll enjoy facebook experience
Thank you for those steps!  I definitely see the problems you mention.

The combobox dropdown appearing in the wrong place in this case looks like bug 599938: all this stuff is inside a div which has style="position: absolute; left: 0px; top: 0px; z-index: 1; cursor: -moz-grab; -moz-transform: translate(0px, 254px) scale(1);"

If I change it to use "top: 254px" and not use -moz-transform at all, both of the issues disappear.

For the combobox, that's expected for the moment due to bug 599938.

For the other, I suspect that jQuery is trying to place the calendar by examining the position of the date textbox on the page, but the positions jQuery sees are not affected by transforms (see bug 591718).

If this is your code, is there a reason you're using -moz-transform here instead of just setting 'top'?

Note that the other browsers you list in comment 0 don't support CSS transforms, so presumably you're setting a nonzero 'top' value for them.
Depends on: 591718, 599938
Your expertise exceeds my highest expectations, and I thank you for that.
Indeed, when I replace -moz-transform with top (in firebug), everything is shown correctly.

The problem is that even that the code is mine, the specific part with -moz-transform is generated by google map.

Same line, where in Firefox is used -moz-transform, looks like this in IE8
[code]
<div style="z-index: 1; position: absolute; top: 0px; cursor: url(http://maps.gstatic.com/intl/en_us/mapfiles/openhand_8_8.cur), default; left: 0px;" __e3_="[object Object]">
[/code]
I suppose that the last part (_e3_="[object Object]") is related to position, but I'm not familiar with that kind of annotation (you'll notice that the top is also set to zero). And there's no -moz-transform in the code.

The part of code that I crate is starting with
[code]
<div class="setloc">
</code]
I'm wondering if somehow I can override -moz-transform with top, so that it's not inherited from parent tag.
There's one thing I'm not sure about.
Whose responsibility is this issue?

Since -moz-transform is generated dynamically by google map, I don't see the way to override it, and haven't find a way to resolve it.

So, is Google responsible by not properly create -moz-transform, of Firefox has a bug by not properly handle the property.
From whom I can expect solution?

Thanks.
> I'm wondering if somehow I can override -moz-transform with top

Your best bet is probably to style the outermost child of that transformed div that you control with "-moz-transform: translate(0px, -254px); position: relative; top: 254px", assuming that doesn't break anything else.

> I suppose that the last part (_e3_="[object Object]") is related to position

No idea what Google maps is doing there... ;)

As for responsibility....  The experimental -moz-transform implementation definitely has bugs (see comment 9 bug links).  Those will get fixed at some point before the prefix is removed.  As far as Google relying on experimental and knon-buggy features, that's something to take up with them.
Thanks for the tip.
Making revert -moz-transform value on outermost child is working when set with firebug, but wont work as harcoded value since it has to be done dynamically.
The value is not always 0px,254px, but it's changing every time the map is moved. I'll try to add listener on map center change event and recalculate current value.

Anyway, thanks for your expertise and keep the good work :)
For anyone who find it interesting or useful, I made small snippet to handle this issue (at least in my app) until it's fixed.
After trying with bunch of google map listeners (none of them fires at the end of map movement), I ended up with hover jquery function to initiate -moz-transform override method.
For now it's working ok (except for time plugin).

update_position = function(){
	var browser = $.browser;
	if ( browser.mozilla && browser.version.slice(0,3) == "5.0" ) {
		var styleMoz = $('#map_canvas > div > div > div').css('-moz-transform').replace (/\(/g, "").replace (/\)/g, "").split(",");
		var index = styleMoz[4].indexOf('p')-1;
		var t1 = styleMoz[4].replace(/^\s+|\s+$/g, '').substring(0,index);
		index = styleMoz[5].indexOf('p')-1;
		var t2 = styleMoz[5].replace(/^\s+|\s+$/g, '').substring(0,index);
		var t1t = t1;
		if(t1!=='0'){
			t1 = parseInt(t1)*-1;				
		}
		var t2t = t2;
		if(t2!=='0'){
			t2 = parseInt(t2)*-1;
		}
		$(<outermost child id>).css('-moz-transform','translate('+t1+'px,'+t2+'px)');
		$(<outermost child id>).css({'position':'relative','left':t1t+'px','top':t2t+'px'});
	}
};
Reproducible for me on Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:6.0) Gecko/20100101 Firefox/6.0 (beta 5)

Setting resolution to NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a duplicate, if you read comment 9.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.