Impossible to get add-on bar height using Javascript?

[SMU]

I'm struggling to find a working solution, but is there one?

[LoudNoise]

Are you creating an extension?

[patrickjdempsey]

The add-on bar is going away in Firefox 29, so it's probably a bit late. Also, if a toolbar is hidden, it won't have a height.

[SMU]

Are you creating an extension?

No, I'm developing a website and I need this information for a special feature -using stage3D.

[LoudNoise]

Moving to Web Development.

[patrickjdempsey]

Are you creating an extension?

No, I'm developing a website and I need this information for a special feature -using stage3D.

Websites are not allowed to have access to the browser chrome. You should be able to get the viewport height using:

https://developer.mozilla.org/en-US/doc ... nnerHeight

[SMU]

Are you creating an extension?

No, I'm developing a website and I need this information for a special feature -using stage3D.

Websites are not allowed to have access to the browser chrome. You should be able to get the viewport height using:

https://developer.mozilla.org/en-US/doc ... nnerHeight

Thanks, but that's not what I'm after. I actually need to find the exact position of the client area in relation to the browser window. Since there are n toolbars, address bars, bookmark bars and who knows what else at the top of the client area, the most logical thing is to start from the bottom where there is only the addon bar, and subtract its height from the client height (and add the browser height). So, is there a reliable way to find out the exact Y position of the client area in relation to the window.screenY, or the required information is missing and fuzzy as usual?

[patrickjdempsey]

I'm pretty sure that would require access to functions that are restricted and cannot be accessed at all by websites. But the height of the addon-bar is not all you would need anyway. That still would not account for other toolbars, the findbar, sidebars to the left or right, and the width of the OS border (which the user can change to whatever he likes). Also, I think you will discover that even if you find some JS method of getting the exact actual screen position in one browser, it likely won't work in another browser. It will also likely fail on computers setup with multiple monitors/desktops.

Anyway, this all seems like something that stage3D should have APIs for?

[SMU]

I'm pretty sure that would require access to functions that are restricted and cannot be accessed at all by websites. But the height of the addon-bar is not all you would need anyway. That still would not account for other toolbars, the findbar, sidebars to the left or right, and the width of the OS border (which the user can change to whatever he likes). Also, I think you will discover that even if you find some JS method of getting the exact actual screen position in one browser, it likely won't work in another browser. It will also likely fail on computers setup with multiple monitors/desktops.

I only need the Y coordinate. From early tests, I've seen it would work at least for two or three popular browsers.

Anyway, this all seems like something that stage3D should have APIs for?

It should, but it doesn't (it does only in apps, not online). I have to call Javascript functions from Flash.

BTW, I can't believe the lack of consistency on web "standards," even on the naming. There are two simple pieces of required information for each object: Position X, Y and dimensions With and Height. Instead, there is a whole variety of confusing naming (internal, external, offset, margin, screenX, window, client etc) and in all that confusion there is always missing and undefined information! The whole web-dev thing is limited and time-consuming for no reason!

[patrickjdempsey]

Well part of the problem is you are doing something that web technology was never designed to do. Websites exist relative to the browser viewport... not to the screen. It seems *really* strange that stage3D would be requiring you to use screen coordinates instead of viewport positions, and not providing an API?

Also, I'm not sure how you could possibly have a solution that works in any browser... just try playing around with different toolbars and OS border widths and I think you'll see that whatever method you are using to guess viewport screen position is probably off.

[SMU]

Well part of the problem is you are doing something that web technology was never designed to do. Websites exist relative to the browser viewport... not to the screen. It seems *really* strange that stage3D would be requiring you to use screen coordinates instead of viewport positions, and not providing an API?

Stage3D isn't requiring anything like that. It's what you said previously, I'm just doing something out of the ordinary, so I'm asking out of the ordinary questions -or data, but that's not an excuse for the lousy work done on the browsers and the poor made "standards". The browser developer can't (and shouldn't try to) imagine and predict the whole range of possible applications and concepts, that's naive and utopian -he is not God!
He should just make sure he has made a consistent and flexible model available with all the fundamental functions and data included, without any arbitrary exceptions.
For example, In this case, the browser dimensions and position (relative to its parent -the desktop) are provided, the browser's viewport dimensions are provided too, but the viewport's position (to it's parent -the browsers' origin or reference point) is NOT! This is clearly an unjustifiable and therefore arbitrary exclusion of just two numbers, which inevitably excludes a possible set of ideas (mine is just one of them) and therefore also a set of user benefits, for no reason. Even if ideas to use those two numbers were rare, it would still result to limit innovation, which is really bad, because innovation is what moves things forward -even if it happens rarely.

[patrickjdempsey]

Hey, I'm with you on the standards and the browser's implementations of them being deeply flawed, but if you actually want some kind of assistance you are going to have to provide some more information about what you are trying to accomplish.

As far as your assertion that this limitation is unjustifiable... I don't agree. Websites live inside the viewport. Period. Trying to be too clever almost never results in any kind of benefit to the user, just headaches when it doesn't work. The limitations are there for security purposes. If you don't want to follow the security limitations of browsers then you should be building applications that run at the OS level.

[SMU]

Hey, I'm with you on the standards and the browser's implementations of them being deeply flawed, but if you actually want some kind of assistance you are going to have to provide some more information about what you are trying to accomplish.

Thanks, but I'm convinced by now, there can be no assistance in my case, except of the possibility to include a specific variable on the next Firefox versions that would benefit a new class of websites (not just mine), but we'll talk about that at a later time.

As far as your assertion that this limitation is unjustifiable... I don't agree. Websites live inside the viewport. Period.

So providing the viewport position would make it 'live' outside? Why is the browser position provided then?

The limitations are there for security purposes.

Too general, therefore not true. Some limitations are there for security purposes and some other because of poor work.

If you don't want to follow the security limitations of browsers then you should be building applications that run at the OS level.

Only the unjustifiable ones, but there is always the option to change reality than adapting to it