Basically, in IE11, when you try to print preview (or print, for that matter) this page (and a few others on this site), the page never renders in the preview pane and the number of pages climbs up infinitely: http://www.greatjakes.com/recent-work/
This bug can also be found on pages like these:
http://www.greatjakes.com/news/
http://www.greatjakes.com/news/kegler-brown-website-honored-as-one-of-the-top-sites-of-2014/
http://www.greatjakes.com/blog/the-disappearing-homepage-traffic-is-down-17-on-homepages-of-law-firm-websites/
I've only been able to experience it in IE11. IE8 is fine.
It is not JS-related. If you remove the JS from the page, it still occurs.
If you remove the CSS entirely, it goes away, but that is missing the point.
If you remove (using in-browser developer tools) the HTML elements within the #content-inner > .page block one by one, you'll find that the page actually prints properly when you reduce the number of elements down to about 5 (3 in some pages).
Other than that, I have no idea what is going on! Any help would be appreciated.
We managed to narrow the issue down to a single CSS rule:
#footer {
display: inline-block;
}
We solved the problem by changing "inline-block" to just "inline" within the print-only CSS - but that won't help others fix their own problem because the bug probably manifests itself based on a number of random circumstances. It seems the key was to narrow down the cause. To do this, I simply deleted chunks of CSS until the page actually rendered in print preview. Once I deleted the chunk that was causing the problem, I restored everything and then worked within the critical chunk and deleted the CSS rule-by-rule until it worked. Once I figured out the exact line that was causing the bug, we changed the rule within the print-only CSS (no need to change how it looked in the standard CSS).
Related
I have been working for hours to figure out why my CSS is not being applied for printing an HTML page. I have created a working example of the markup I am rendering with dompdf:
https://jsfiddle.net/n7Lak0gr/1/
The HTML and CSS is a directory with multiple columns in a table. The rows have an alternating background color, and there are some other styles as well. But upon printing to a PDF, the styles do not show, even if I have media set to all.
Note that if you copy all of the code from this version and create your own local html file, you can see it better, since another issue is that the table overflows into multiple pages when the styles are not applied.
I have reproduced the issue in Chrome, Firefox, and Internet Explorer. And I have tried removing pieces of the CSS, but I cannot figure out why the styles don't show.
It is the default setting of most browsers not to print backgrounds. Obviously this is to save ink/toner.
You can change that setting in the browser preferences, but the bad thing is that you can't influence those via your website - it's purely a decision of the user who does the printing (and most users don't even know about this preference setting)
I figured it out. I had to delete the font cache file dompdf_font_family_cache.php located in sites/all/libraries/dompdf/lib/fonts/.
I was pointed in the right direction after seeing some other errors and viewing this SO answer
I'm using Bootstrap to build a webpage. The page looks as it should on desktops and laptops. However, when viewed on mobile phones, the bottom half of the page's content is cutoff. This happens only on mobile phones or windows resized smaller than 991px wide.
I tried sifting through the included Bootstrap CSS file but couldn't find any style rules dictating any behaviors like the one I describe.
I've attached two screenshots: Fig. 1 is the intended behavior--the content ends with the embedded contact form. Fig. 2 is the puzzling behavior--the page just ends in the middle of the pricing table.
The site is grillemasters.info
[Fig. 1] http://i.stack.imgur.com/uH7MB.png
[Fig. 2] http://i.stack.imgur.com/h2190.png
Without seeing more information (e.g. try to post the minimum amount of HTML that still exhibits this error) it's hard to prescribe a solution. But here are three possible things to check out:
Mismatched (Incomplete) DOM
If you have an open-element (e.g. <div>) without its close (</div>), HTML behaves in mysterious and often irreproducible ways. This often includes mis-styling all elements after the mismatch.
Bad Character or Incomplete File
If you are uploading via FTP and the connection is interrupted, you may only be looking at a fragment of the file. Try deleting and re-uploading. The same thing would happen if the browser or FTP client encountered a character that made it stop reading the file — both of which might lead to a mismatched DOM.
Unnecessary body CSS
Make sure you don't specify the height of body or html anywhere (or any other global, all-containing elements). The page should flow naturally, without you specifying a height: 100%.
[EDIT] I looked at your site (which redirects to http://www.supsean.com/grillemasters/, in case others are interested in debugging outside a frame). Look at the top of your page when you resize the screen to such a small size; there are quite pervasive CSS issues, likely caused by position: fixed or absolutes where they needn't be.
Try resolving that, and I suspect you'll stumble across the solution to this question as well.
I came across a weird bug with jsfiddle. The layout I get when I visit the site is completely broken. This bug happened when I dragged the vertical resize bar while my second display disconnected. See this the result:
There is probably a way I can get this fixed from the inspector by resizing it manually, locating left panels and changing their width manually and than playing with the vertical resize bar; I'l keep investigating.
Where are the layout positions stored?
Before asking this question, I tried to reset my cookies, I had a look into local storage and session storage (they were both empty). I know it's a local issue because jsfiddle is too awesome to break like that, it's not because of the code in the fiddle, I opened the fiddle in private navigation and worked like a charm.
Edit: I fixed my issue by deleting .column.left, #handler_vertical appeared, I moved it and now data is fixed, but I still don't know where this is stored ;)
I had this same issue and worked out that it was after I reduced the size of my browser window, I'd accidentally moved the vertical bar left, which caused this to 'disappear', so when I resized the window to full, no vertical bar!
To fix, I searched the inspector element for 'handler_vertical', and around this were column left and column right, with widths set inline. Simply remove these inline widths and it's back to normal.
Strange that some js is still adding itself even after clearing cache and cookies!!
I accidentally deleted an HTML node in Chrome's inspector, which broke JSfiddle's layout.
When I reloaded the page, I was surprised to see the layout was still broken.
I cleared my cache and made a hard reload, but JSfiddle's layout was still broken!
The solution came out recently : I changed Chrome's theme... and it fixed JSfiddle.
Sometimes you just don't want to understand.
I know this was solved a while ago, but I just wanted to add that the FAQ acknoledges this and pasting Layout.setWindowSizes(null)into the browser console fixes the layout.
Source: http://doc.jsfiddle.net/faq.html
Same just happened to me, reloading the site had no effect but deleting last cached elements made it
After some changes to our site, we are seeing that when certain pages are loaded, the page quickly changes width. This occurs every time on webkit browsers Chrome and Safair, but only rarely on some other browsers.
I have not been able to produce the effect at all on Firefox on Windows, Firefox on Mac, nor IE9 and IE11. It seems to rarely occur on IE8 and IE10. I have not found a pattern yet that causes it to appear on IE8 and IE10.
To understand what might be causing this, it would be good to know if certain styling attributes take an initial value while the page is loading but them assume some other value by the time the page is fully loaded. This could explain what is happening.
I should add that this problem developed after some changes which "should" not have caused this issue. Basically having to do with adding URL rewriting to eliminate duplicate pages. Clearly some side effect is operative.
At the moment we only have the code on development servers, so it would not be that easy to actually see it right now, although that is the obvious first question from a responder. So at this point, the question is more "what generically causes pages to reformat under Webkit."
UPDATE: the problem seems to be traced to Google Translate. When I remove that from the page, the problem goes away. Put it back; problem comes back.
Oddly, it mostly impacts Chrome! IE10 and 11 are exempt, and with even earlier IE versions the problem is much less.
I can readily demonstrate the temporary widening of the page just by reloading the page.
I experimented with trying to put the div containing the translate div instead a container div and setting some attributes on that. So far I have not found something that mitigates the problem.
We have suppressed Google Translate recently because it started adding other junk to the bottom of the page. That other junk is gone but we will continue to suppress it due to this new jumpiness.
I believe there is some clever way to contain the issue, but have no more time for it.
I have confirmed that the issue is definitely caused by Google Translate being on the page.
Has anyone seen the following rendering bug in google chrome:
bug http://community.mediabrowser.tv/uploads/site_1/126/annoying_rendering_bug.jpg
I get it occasionally when I navigate to http://www.mediabrowser.tv
What causes it? Is there any workaround?
I can't reproduce this right now, but I've seen similar in the past. Generally this happens when the element with the background is not full height.
Be sure you are applying the background to the body (which defaults to height 100%) and that you are not applying styles to the html tag (which would throw off the body rendering).
Try inspecting that white bit when next it happens. You might gain more insight into what's going wrong.
Another possibility is that the page hasn't finished loading the GA code at the bottom. If your script blocks at the end of your page take too long to execute you might see this before the closing html tag is rendered.
Possibly related: Chromium issue 5388
omitted close tag...
It is possible that a closing tag was omitted.
I'm running Google Chrome as well, on Windows XP and I am not having a problem with the Rendering. Try closing your tab and reopening sometimes it has a caching type of error like most browsers do occasionally.
Part of the problem lies in specifying a height for the container while floating elements inside. Parent elements are never to expand to contain floated children. The only thing preventing this from collapsing altogether is the p element inside the last div. I'm not sure Chrome is doing anything wrong though Firefox is different but I don't have time to look at it further right now.
This could be the reason, <div style="overflow: auto; height: 400px;"> if you forget adding overflow: auto to your style or somewhere in your stylesheet that truncation happens. IE can accomodate that, but not Chrom and FireFox. Some default height is necessary but not sufficient. W3C validator pass the code without that elaboration since it does not consider the semantic (logical) errors.