Using GWT 1.6.4, I have the following code to retrieve the dimensions of the browser window:
RootPanel panel = RootPanel.get();
int height = panel.getOffsetHeight();
int width = panel.getOffsetWidth();
Now, in the Hosted Mode browser, and in IE (but I believe the hosted mode browser uses IE, right?), this returns the correct values for both width and height. However, in FF3, width gives the correct value, but height is always zero. Can anyone explain this? Am I doing something wrong? What is the correct way to retrieve the height of the window in Firefox, and is there one method that works correctly in both IE and Firefox?
Did you try the Window.getClientHeight() and Window.getClientWidth() methods?
Check out the JavaDocs.
Using javascript, you can grab the window height with:
int height = document.body.clientHeight;
Now whether GWT gives you anyway to specify specific javascript pieces, I don't know. You may want to post in the GWT google group, which can be found at: http://groups.google.com/group/Google-Web-Toolkit?pli=1
I'm taking a wild guess here: in Firefox, in the moment you check RootPanel.get().getOffsetHeight(), it's empty and not stretching into the viewport, only horizontally.
So better use Window.getClientHeight() if you need the actual window/viewport dimensions.
Related
I have a piece of code that rely's on correctly measuring the width of the text. Most of the time, I am trying to measure the width of whitespace in current font that has been set.
While this generally works - I have seen instances in production logs that the ctx.measureText(' ').width was zero.
I did some digging around - The font size is never zero. It is always double digit in px.
I looked at the chromium codebase and it seems that the TextMetrics object is always created a new object.
Does anyone know what else could be causing this to be zero ?
I figured out why this was happening.
The font that was set in the canvas context was getting downloaded. It was not available to the browser.
Chromium code
const SimpleFontData* font_data = font.PrimaryFont();
if (!font_data)
return;
I am trying to set up a simple blog using Metalsmith and the fullPage.js library.
At the moment I have a problem where the height of the section divs upon intial loading are roughly 2 times the correct size.
Ie. when it initially loads the height in the console reads 1563px.
The odd thing is that once I resize my browser window in any way ie. make it larger or smaller, the div(class='section') height will then resize to its correct height in the console and in the browser, and everything is laid out correctly again (with regular sized divs as opposed to the super tall ones that were there previously.
This initial height inconsistency is causing many issues with alignment in my layout, such as the prev/next arrows as well as the div content.
here is a link to my public git repo for this project.
If you want to run this locally you can pull it down, run npm install, then run nf start. You will then be able to access it at localhost/3000.
If anyone has any suggestions that would be much appreciated.
Thanks.
It is not ideal to just public your source. A link reproducing the error would be much better.
In any case, I believe yours is a case of missing the compulsory DOCTYPE declaration at the very start of the page.
Take a look at any examples of fullpage.js. They all have it.
Add this in the first line of your resulting HTML files:
<!DOCTYPE html>
Firefox under version 28 has an issue where a path with a stroke-dashoffset property will render differently depending on the stroke-width amount. There is a known fix which is to divide stroke-dashoffset with stroke-width, but applying this across the board will mean other browsers will now display incorrectly.
https://bugzilla.mozilla.org/show_bug.cgi?id=661812
The quickest solution I can think of is is simply check for browser type and version number, but generally this seems to be regarded as a bad idea. Does anyone know a way to test the result without going down this route?
I have put together a Codepen which allows you to change the width of an animated offset, and a toggle for the fix so you can see for yourselves in different browsers. http://codepen.io/MattyBalaam/full/lGJkc
I've been checking into some issues with Facebook Like Box plugins on websites my company manages, and have seen different behavior in the past two days. Can anyone help to explain if this is more likely an issue with Facebook, or the target profile/page settings?
I'll focus on the more obvious one here.
When the 'Show Faces' option is disabled and no Data-height is explicitly specified for the plugin, the area to display the Stream activities is reduced to 0 and all that is displayed is a double horizontal line.
Working from the Developers.facebook demo page
(https://developers.facebook.com/docs/reference/plugins/like-box/)
1) Enter a valid facebook Page for the address
-- Defaults should display with width=292, height blank, and all other options checked.
2) un-check 'Show Faces'
-- Like Box shrinks to only display Header, and the Social Plugin footer.
3) Enter a Height value ( anything above 150 px should display some area of content and the vertical slider again, but with the Like Box total height restricted to the height entered)
(I wanted to post this to Facebook as a Bug report, but could not find the correct steps to do so.)
Facebook must have changed something. This only seems to be affecting the HTML5 implementation of this plugin. Some other sites which I maintain, which use the iframe implementation, do not seem to be affected.
I just added a fixed 'data-height' attribute to the 'fb-like'box' div of the HTML5 implementation of the plugin - seems to have done the job.
Looks like they have changed (or broke) the default value for height from "300px" (I think that is what it was) and replaced it with the 120px which leaves no room for the stream. If you add faces it ups the default value and leaves room for the stream.
If you change the height of the box to say 600px (depends on what you want) then even with faces off it will show the stream.
For example if you goto: https://developers.facebook.com/docs/reference/plugins/like-box/
Then turn stream on and faces off (even on the default site of FB Dev) it will still hide the stream with no height specified. Then change the height to say 600px the stream will appear.
Feels like less of a bodge than the other method that Nathan mentioned (which I couldn't get to work anyway! :( LOL)
Hope this helps someone else. :)
I have image png in resolution 829x597 generated by php gd.
How force user browser, to print it in dimensions 11.5 cm width 7.5cm height. ?
User hit, ctrl + p, hit print, and output image on paper should have 11.5cm x 7.5 cm
Please help
Regards
Presumably, you're talking about from a browser, in which case, you can't directly, as PNG doesn't store print resolution.
However, if you embed the PNG in a webpage and specify its width in inches/cm/pt, then the browser will respect that and print it at the correct pixel density.
After few hours of printing 100 pages with other dimensions, for example in pt, i finally found where problem is.
So i have inside CSS information width:10.5cm; height:7.5cm;
Chromium browser will print 12cm ^^ and 8cm heigh...
After change to firefox, everything work well...
It's some kind of a browser bug... i was thinking that's my problem... but as You can see... it's browser...