Bug Tracker

Opened 11 years ago

Closed 10 years ago

#13416 closed bug (invalid)

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:


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.

Change History (9)

comment:1 Changed 11 years ago by dmethvin

Owner: set to can3p
Status: newpending

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?

comment:2 Changed 11 years ago by can3p

Status: pendingnew

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

comment:3 Changed 11 years ago by dmethvin

Status: newpending

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

comment:4 Changed 11 years ago by can3p

Status: pendingnew

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

comment:5 Changed 11 years ago by dmethvin

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

comment:6 Changed 11 years ago by can3p

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.

Version 0, edited 11 years ago by can3p (next)

comment:7 Changed 11 years ago by Timmy Willison

Component: unfiledoffset
Owner: changed from can3p to dmethvin
Priority: undecidedlow
Status: newassigned
Version: git1.9.1

comment:8 Changed 10 years ago by dmethvin

Owner: changed from dmethvin to can3p
Status: assignedpending

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?

comment:9 Changed 10 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

Note: See TracTickets for help on using tickets.