Scrolling to wrong position about chrome-type-ahead

[GoogleCodeExporter]

I cannot reproduce it. I see the word highlighted and correct scroll:

http://www.2shared.com/file/10426157/bbbbc790/taf-shot1.html

please report with screenshot (if possible on a lighter page)

Original comment by tokland on 3 Jan 2010 at 4:03

[GoogleCodeExporter]

You can see my screenshot attached.
I´ve discovered the problem!
It´s because I use zoomed pages at 125%.
It´s likely you need to multiply the position by the zoom level.
I use the extension AutoZoom for setting the default level.

Original comment by [email protected] on 3 Jan 2010 at 5:34

[GoogleCodeExporter]

Oh, ok. This seems a pretty nice extension, but the way it changes zooms fools 
JS scripts. With JS there is no 
zoom factor, you only ask position for elements to the DOM and it responds 
correctly, with the current zoom 
applied. But when the extension changes the zoom the DOM returns inaccurate 
values.

How to test:

function getElementPosition(element) {
  var width = element.offsetWidth;
  var height = element.offsetHeight;
  var selectedPosX = 0;
  var selectedPosY = 0;
  while(element) {
    selectedPosX += element.offsetLeft;
    selectedPosY += element.offsetTop;
    element = element.offsetParent;
  }
  return {x: selectedPosX, y: selectedPosY, width: width, height: height};
}

Use this function with an element. Modify zoom (standard way). See how 
positions are logical. Do the same but 
using the extension. See how returned vales are not good.

You can ask the extension developer, if the problem is in my getElementPosition 
code I'll change it.

Original comment by tokland on 3 Jan 2010 at 6:06

[GoogleCodeExporter]

As you described, it seems to be a bug of Chrome, not the AutoZoom level.
Can´t you get the actual zoom level and force a multiplication of it by the 
selectedPosY for determining the correct scrolling position?

Original comment by [email protected] on 3 Jan 2010 at 7:16

[GoogleCodeExporter]

- To change zoom level in chrome (real-time): document.body.style.zoom = "150%"
- Changing the zoom level that way everything seems ok.
- See zoom.js in autozoom. It uses document.body.style.zoom, but in my tests 
getElementPosition 
returned weird positions. Example: Get position of any element with a given 
zoom level, then ctrl+] 
and ctrl+[, get position again, you get a bigger number. Do it again, you get a 
bigger number. And so 
on...

As I see it, there is something wrong with the extension.

Original comment by tokland on 3 Jan 2010 at 7:53

[GoogleCodeExporter]

Another test:

- Change zoom with Autozoom
- Press link 'My favorites' (up-right on this page)
- Menu appears in wrong possition

Original comment by tokland on 3 Jan 2010 at 9:04

[GoogleCodeExporter]

There is another extension called ZOOMY that has the same function of Autozoom.
The compatibily problem with Type-Ahead also happens with this other extension.

Original comment by [email protected] on 3 Jan 2010 at 10:56

[GoogleCodeExporter]

Can you do the "my favorites" test with both of them?

Original comment by tokland on 3 Jan 2010 at 10:59

[GoogleCodeExporter]

Oh, sure, I forgot to tell you: there is no wrong position of "My favorites" 
when I 
zoom the page with Autozoom or Zoomy (see the attachment)

Original comment by [email protected] on 3 Jan 2010 at 11:05

Attachments:

• screen.jpg

[GoogleCodeExporter]

I restarted chrome and now the menu's working well.

However, the main problem remains: element positions returned by the DOM after 
autozoom changes are just chaotic. I'll try to create an HTML+JS so you can 
test in 
Windows.

Original comment by tokland on 3 Jan 2010 at 11:45

[GoogleCodeExporter]

More:

- AFAIK chrome standard zoom is not accessible in any way from JS.
- element positions are well adjusted when standard zoom changes.
- document.body.style.zoom is the way autozoom changes zoom level.
- element positions are not adjusted when document.body.style.zoom changes.
- FF does nothing when you change document.body.style.zoom, so we cannot 
compare.

I uploaded a HTML to test (100% ok, 150% fails):

http://tokland.freehostia.com/test-zoom.html

As I see it, it makes no sense that JS code has to apply corrections checking 
zoom levels.

I think element positions should change when style.zoom changes. I'd say it is 
a problem with Webkit.

Original comment by tokland on 4 Jan 2010 at 1:08

[GoogleCodeExporter]

Thanks very much for you attention and efford to fix this problem.
Your uploaded html is awesome and proves that the problem is really with 
Webkit. I´ve 
made a small change to its code (I created a global variable called "newvalue" 
and it
´s the same value as the variable "value". The scrolling then multiplies the 
newvalue 
with the Y position of the element).
See the attached file.
I know it´s a bad workaround but, believe on me, it´s much easier than 
convincing 
someone of the Chrome team to fix the problem with Webkit.

Original comment by [email protected] on 4 Jan 2010 at 2:19

Attachments:

• test-zoom.html

[GoogleCodeExporter]

I am no JS expert, so testing those kinds of things is a good way to learn.

Not being really sure if applying zoom level is DOM's responsibility, for now 
I've modified the 
extension (r87). I only check zoom in body, not the elements tree. 

Anyway it would be great if you can report Chromium (or Webkit?) developers. 
Using test-
zoom.html is very easy to explain and reproduce the problem. I tried also with 
Konqueror (KHTML) 
but -as FF- it does nothing. With nothing to compare, we don't know "what's 
right". 

BTW, 'zoom' is fairly new, CSS3:

http://www.css3.com/css-zoom/

Original comment by tokland on 4 Jan 2010 at 7:33

• Changed state: Fixed

[GoogleCodeExporter]

Your extension is just **perfect** now!
By the way, you could translate the word "of". In Portuguese (my language), it 
means 
"de", like "1 de 10" (1 of 10).

Original comment by [email protected] on 4 Jan 2010 at 11:12

[GoogleCodeExporter]

Ignore my last suggestion! I myself translated that word on the js file. I 
don´t want 
to give you more work than I´ve already given.
Have a nice 2010!

Original comment by [email protected] on 4 Jan 2010 at 11:15