Given a complex JS application produced by GWT I need to use the complete browser area WITHOUT let scrollbar compare but not disabling them because there's a couple of exception to the rule, i need then to calculate the client area and since the tool selected it would be better directly in GWT but as it is supported also pure JS solution are acceptable.
as usual all browsers (chrome, safari, ff) except IE11 works fine with a standard solution of
rootPanel.setPixelSize(Window.getClientWidth()-1, Window.getClientHeight()-1);
but when it's used in IE11 on a screen 1440x900
the value of getClientHeight is 1440x845 (seems ok) but after rendering using this space scrollbars compare wasting space, exactly 10pixels..
rootPanel.setPixelSize(Window.getClientWidth()-1, Window.getClientHeight()-10);
seems to solve..where are gone this 10 pixel comparing the result with other browsers?
I think contents are not relevant since the size is set on body and first div
<html>
<head>...
<body style="width:1439;height:xxx;">
<iframe out of visibility (position absolute and visible false
<table style="width:1439;height;xxx">
and so on
Any guess where 10pixel can be lost?
Edit: I was forgetting an important detail: all happens when browser is maximised, if the browser is n't all seems working as expected!!!
Edit: looks like something close if not the same of
$(window).height() issues in IE and FF
change just the origin of my JS code that comes from GWT but at the last stage should be the same, but still not solution
Solved: when maximized the actual size is available late...the resize must take the size in a deferred moment, the module load usually implemented in GWT isn't the right time for this browser in the specific state..
Related
Question
I have a situation where the Firefox page render does not match the inspector html- that is, if I copy the inspector's outerHTML into a new document, it renders correctly. How is this possible?
Is this definitely a Firefox bug, or is there some intermediate render state where the inspector output has been updated but the page view hasn't? (If so, how would I force the render to progress past this intermediate state?)
Extra Details
I can also "fix" the render by manually (in the inspector) editing the attributes that aren't displaying correctly.
Specifically, for example, I might have a case where the code is calling setAttribute('width',10), which causes the inspector to say width="10" but causes the page to display whatever the width was previously set to. If I manually replace the width="10" with width="10", nothing happens; however, if I change width="10" to width="11", the width displays as 11, after which I can set the width to 10 again to make it display correctly.
Unfortunately, I have not yet been able to devise a simple example demonstrating this. My specific case is entangled with a fair amount of rendering code and involves changing dimensions on svg foreignObjects, but I'm mainly interested in the answer to the general question of how the inspector and page render can ever be out of sync.
(I have not been able to reproduce the issue in any other browsers, because Firefox is currently the only one that actually handles foreignObject correctly.)
Firefox Version: 51.0.1 (64-bit) on Mac 10.10.5
Updates
The main question still stands, but I'm increasingly thinking that a subtle Firefox bug is at the root of this. Some reasons:
Refreshing the page sometimes changes the behavior and sometimes doesn't.
I have tried adding getBBox calls right after each setAttribute, to force the browser to recalculate layout. This seems to work for every foreignObject- except for the first on the page. (However, sometimes the first one shows up- seemingly without anything being changed.)
JQuery's .attr seems to produce different behavior than .setAttribute and .setAttributeNS
I am doing a web application. While trying to open the webiste on UC mini browser in data saving mode from my mobile device the css styles are not getting compiled.Is there any way to debug?
Thanks in advance.
There are no very good ways to debug it. UCMini (or UCWeb in light speed mode) is a remote proxy browser. As far I know, there is no debug console for it. The only thing you can do is throw JavaScript alert()s to try and debug various JS breakage issues.
But if you are concerned about a very weird layout. Keep in mind that you will never see a normal CSS in those modes. UCMini is not a normal browser. It's a Firefox 10 proxy engine that will shrink your content into a single column, in a similar way Opera Mini does in single column view mode.
A couple good other helpful things to know about that browser's context:
The target screen size is 800x600. So in portrait, it shrinks it all to approximately 600px (in one column), and 800px in landscape. And due to the Firefox 3-10(ish) engine, CSS support is limited.
I could say about our experience (FareCompare.com). Nodejs consoles + Frontend (Dojo) alerts. That's all we could find for our few bugs.
P.S. Pay attention that UC is working in one page mode. As far as I know, it is impossible to open new tab there. window.open() works the same as location.replace( url ).
I have been researching all over the internet about this, and unfortunately cannot find out why this is happening. It seems to only be happening in internet explorer 9, on certain computers.
The entire page looks like a mess only in IE 9 (some computers):
The URL of the website is Here
Can anyone tell me why this is happening in IE9?
(NOTE: Compatibility view cleans it, but then the Js/jQuery doesn't work right).
For some reason, IE thought that the site was in my intranet, and rendered it in Compatibility Mode (there's a setting in IE to automatically render intranet sites in CM).
When I unchecked the box to "automatically detect intranet network", the site rendered correctly.
So your real question is how does IE determine the intranet network, and how can you force your page to NOT render in Compatibility Mode... something like this.
I noticed that you have blank space above your doctype. IE hates this. The doctype needs to be the very first thing in the file.
You also have over 2300 HTML validation errors that should be investigated and rectified. Again, IE is very sensitive to invalid HTML.
Going on a whim here, but I think it's the usage of inline-block. I don't have IE9 installed to a point where I can use it's developer console to further inspect, but IE is known to be very bad about displaying inline-block elements.
In Google Chrome's console, I am able to replicate the same appearance using float:left as opposed to display:inline-block, so that should solve that piece of the issue.
Edit: The only syntax issue I see with the HTML is the placement of the </head> tag, which is not adjacent to the <body> tag.
Edit 2: As far as the outlining issue goes, try using this answer to another question.
Edited yet again to fix the display of the tags.
When I'm testing my website on a normal notebook, I have no problem with my website but when I'm testing this website on a Netbook (mini laptop) it has a strange behaviour.
You can see the website here:
http://www.benskesblog.com/projects/frontend/project/index.htm
(it works on IE9 and other modern browsers).
When I try it on my netbook the images aren't displayed completely. When I scroll I see another part of the images. Very strang. I've tested it on another netbook (and on other browsers) and I have the same problem. You can see it here:
http://img259.imageshack.us/img259/5168/titel1.jpg
http://img683.imageshack.us/img683/374/titel2k.jpg
Does someone now what's going on?
Thanks!
For starters, IE9 isn't "modern" - it's "bleeding edge".
Also, your page doesn't work at all in IE6 - which is arguably the most common browser out there.
So you've really got two questions you need to ask:
1) What is the minimum browser I'll support (for example, IE9+FF7+Safari5 #1024x768 truecolor resolution)?
2) How will I degrade gracefully for users who don't support my minimum requirements?
We did an application using rails(2.3.4), ruby(1.8.2), MySQL, JavaScript, jQuery. This is handling minimum 6000 records. We showing those records detail in table. In the beginning Mozilla taking 2m to load the whole page. We did the cache, eager loading, indexes. Now Mozilla taking 25s to load the whole page. But IE-7 taking 1m30s to load the page.
We don't know why IE-7 taking too much of time.
Any one can help us to detect the running time in IE-7 and tell your guidelines to improve performance in IE-7.
Any add-on is available in IE7 to see the AJAX request time taken as like Firebug add on.
Use partial loading. Don't try to load the 6000 records at once, load them in smaller segments, when needed. Even 5 second loading is too long, not to mention the 25 seconds or 1m 30s.
Oh and yeah, IE 7's JS engine just sucks.
From Table Rendering - IE Blog:
When Internet Explorer encounters a table it measures all the content
of the table before rendering so that it knows what the widths of the
columns are to render the content correctly. On the other hand Firefox
uses a different algorithm in that it renders the table contents
progressively before it has all been passed.
You can improve performance by setting the CSS rule table-layout: fixed. The renderer will then calculate the layout based on the first row of the table.
IE7 is slow, there's no real way of getting around that basic fact.
I'm going to answer your second question (about debugging tools for IE7) because I don't think I can give any useful advice on your main point about actually speeding up IE7.
Any add-on is available in IE7 to see the AJAX request time taken as like Firebug add on.
The first thing to try is IE8 or IE9. These browsers have a Developer Tools window (accessible via F12, just like Firebug). It isn't as good as Firebug, but it does do quite a bit, and it is a useful debugging tool. It also has a feature which allows you to switch the browser into IE7-compatibility mode. The idea is that you can test IE7 from the relative comforts of IE8 or IE9.
The down side is that it isn't actually IE7. It's just a pretend ID7, and not a particularly good one at that. It may or may not replicate the speed issues you're having with IE7, and it certainly has known bugs and quirks of its own which don't appear either in a real IE7 or in IE8 in normal mode.
But all that said, it might be good enough for you to run some tests and get some answers.
A second suggestion might be to try Firebug Lite. This is a cut-down version of Firebug which runs as a bookmarklet in any browser (but generally IE). It doesn't have all the features of the full version of Firebug, because there's only so much you can do without writing a browser plug-in, but it does do a surprising amount. If nothing else, it does give you the console functions, which can be a life saver for debugging.
I hope that helps.