In IE 10 element offset is calculated incorrectly in virtual keyboard is opened.

Reported by:	can3p	Owned by:	can3p
Priority:	low	Milestone:	None
Component:	offset	Version:	1.9.1
Keywords:		Cc:
Blocked by:		Blocking:

Description

The notebook with touchscreen is required to reproduce the bug.

The system: windows 8, IE 10

If user opens the page and then taps on the input on the page, the virtual keyboard appears and input is centered vertically on the screen and the page is scrolled a bit to do it.

The thing is that it's not a normal scrolling, the browser does not fire scroll event. The window. pageYOffset property is being updated to the correct value but getBoundedClientRect() still returns data as if there weren't any modifications on the page. As a result the element.offset() property returns distorted data at this moment.

The testcase: http://test.dpetroff.ru/test_getBoundingClientRect.html

Tested in jquery 1.9.0 but it should reproduce in the master because I can't find any related fixes in the source.

Attachments (0)

Change History (9)

Changed February 08, 2013 02:41PM UTC by dmethvin comment:1

owner:	→ can3p
status:	new → pending

When I run the test case in the full-screen IE (Modern/Metro) I see it jump as you describe. Here are the values I get before opening the keyboard:

window.pageYOffset: 0
document.body.getBoundingClientRect().top: 8
input.offset(): 424

After opening the keyboard the values are:

window.pageYOffset: 7
document.body.getBoundingClientRect().top: 8
input.offset(): 431

Is that what you are seeing as well?

Changed February 08, 2013 03:26PM UTC by can3p comment:2

status:	pending → new

Yes, exactly. The difference depends on the position of input on the screen

Changed February 12, 2013 03:22AM UTC by dmethvin comment:3

status:	new → pending

What number do you expect, and how are you going to use it?

Changed February 12, 2013 04:50AM UTC by can3p comment:4

status:	pending → new

Offset should be independent on the keyboard presence because the keyboard doesn't change anything in the layout of the page.

Changed February 13, 2013 07:15PM UTC by dmethvin comment:5

Well the window did seem to shift up, didn't it? As far as the document is concerned, the .top stayed the same.

Changed February 13, 2013 08:50PM UTC by can3p comment:6

_comment0:	Yes, the page has shifted. But it just means that the top of he page is hidden in this case and it doesn't mean that the element position has changed bacause it's being calculated relative to the top of the page. And if element has not changed it's position the offset() show give the same results. \ → 1360788635461000

Yes, the page has shifted. But it just means that the top of he page is hidden in this case and it doesn't mean that the element position has changed because it's being calculated relative to the top of the page. And if element has not changed it's position the offset() show give the same results.

Changed March 13, 2013 01:26AM UTC by timmywil comment:7

component:	unfiled → offset
owner:	can3p → dmethvin
priority:	undecided → low
status:	new → assigned
version:	git → 1.9.1

Changed May 02, 2013 09:06PM UTC by dmethvin comment:8

owner:	dmethvin → can3p
status:	assigned → pending

I've created an updated demo here: http://methvin.com/detect/offsetq.html

I *am* seeing scroll events when the keyboard appears.

As for the result of .offset() how is it affecting your later work? That is, does something you position using the .offset() result not show properly?

Changed May 17, 2013 08:39AM UTC by trac-o-bot comment:9

resolution:	→ invalid
status:	pending → closed

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

Side navigation

#13416 closed bug (invalid)