A fellow developer and I are on exactly the same Firefox version (41.0.1) using the exact same steps to reproduce a text-layout bug on our web application after hard cache refreshes using the same production server (no local assets), and he sees the bug but I don't. We tried on a 3rd developer's browser (same Firefox version) and he does not see the bug, so it seems isolated to this one browser instance. Both machines are identical - Windows 7 on Lenovo Thinkpad T420. It's a CSS text layout bug - text overflows the box onto multiple lines. I've linked to an image below.
Image of bug here
We have also tried:
Running the problem browser in private browsing mode.
Starting the problem browser in safe-mode (to disable plugins).
Doing a diff between the CSS source file each browser is seeing - they are binary equal
Does anyone have any ideas why this might happen or how else to try to debug it?
Edits:
Other things we have tried:
Reset zoom levels on both (ctrl+0)
Related
We ran into an error that only occurs on Safari browsers, so I dusted off my OSX partition on my Macbook and am trying to debug it but I can't find out how to see the original source code and set a breakpoint.
My main file is main.d7f60b0631c7822cabf3.bundle.js and the last line of the file is this, which points to the sourcemap file which does exist because I can type in the url and get it, and it works in firefox and chrome:
//# sourceMappingURL=main.d7f60b0631c7822cabf3.bundle.js.map
In Firefox I can go to the debugger tab in dev tools and under sources I see my original source file webpack:///src/app/app.component.ts and I can open it and set a breakpoint.
In Chrome dev tools I go to the 'Sources' tab and do the same thing navigating a tree to webpack:// - . - src - app - app.component.ts.
Is there a way to achieve the same thing in Safari? From memory since I"m writing this on Windows I can't see any files in the debug tab, just a list of breakpoints. In the resources tab I can see the bundle and an arrow that looks like I should be able to expand it, but clicking on that arrow does turn it from right to down like it is expanded but nothing is displayed. Other files like jquery do seem to have the original source under them when expanded...
I had the same question, and found the answer in another posting here:
How do I toggle source mapping in Safari 7?
(short version, in the debugger, command-click on whatever symbol you want to look at, and it should jump to the original source. For reference, I'm working with TypeScript compiled to JavaScript)
The author points to this documentation:
https://developer.apple.com/library/content/documentation/AppleApplications/Conceptual/Safari_Developer_Guide/ResourcesandtheDOM/ResourcesandtheDOM.html#//apple_ref/doc/uid/TP40007874-CH3-SW4
In the process, I also noticed that in the Resources tab in the Safari debugger, it shows the foo.js with a turner next to it, which expands to show the original foo.ts file (and I assume with a more complex source, it might expand to show multiple sources if they get concatenated together?)
Personal opinion: I think the turner is a great solution to this problem... odd that the debugger defaults to showing the "compiled"/"transpiled" source rather than the stuff one is logically wanting to debug.
First be patient while the browser processes all the source maps.
Whenever that finishes, you should be able to search for any original source file by entering the name of that file into the input field located at the bottom of the pane with the placeholder "Filter". It's a pretty counterintuitive UX IMO. Hope this helps someone!
Screenshot:
Ever since Chrome updated itself to version 32, I have been experiencing aggravating bugs. One of the worst is when editing the DOM using the Web Inspector, and Chrome will about every minute start popping up this dialog, which yanks focus from the Web Inspector:
It's complaining about the Web Inspector itself being "unresponsive", when it really isn't, and nothing's gone wrong.
This particular page I'm messing with is making use of the mutation-summary library. Perhaps the bug in Chrome that thinks stuff is unresponsive could be related to setting various continuously-running setTimeouts. I say this because I observe similar behavior in the web app we build at work where this has also started happening (and is equally annoying).
The workaround is I believe it is possible to just ignore the dialog and work can continue. I wonder if anyone else (or everyone else) has been experiencing this issue?
I started getting this problem as well.
In searching, I came accross this issue https://code.google.com/p/chromium/issues/detail?id=335248.
As best I figured out, the bug is related to:
Windows 7/8 with Aero Theme
Scrollbars on pages (such as in the developer console)
Pages with popups (in particular Window.open() calls)
I guess they are slated to push the fix into version 33...and maybe leave the stable* 32 how it is (although I hope not).
So there are a few options:
Switch away from Aero Theme until version 33 is in stable
Upgrade to the beta channel, i.e. version 33
Click on the Wait button every 30 seconds whenever the chrome developer tools is open.
Update:
Chrome has released a hotfix into the version 32 stable channel. http://googlechromereleases.blogspot.ro/2014/01/stable-channel-update_27.html
Thanks to #probackpacker for bringing it to my attention.
I have experienced this as well on Windows, it seems that this will happen in general when using the browser (not only within the web inspector). It also seems to happen more often when loading flash content (such as a game). The browser and flash areas are responding normally, but the browser thinks that they are not for whatever reason. Pressing wait seems to hide the dialog for a few minutes until it will re-appear again.
I've read that this bug is fixed in the next beta (version 33).
Regards,
Moses
I have also experienced this issue. The change of theme workaround has worked, and the Chromium team has provided the following update today:
... We understand your frustration and are actively working to resolve
it. When you add that comment, it’s confusing the comments around
whether we’re able to fully fix it on canary. If we can confirm it’s
fully fixed in canary, we can merge into the stable channel and
everyone can get the fix. So please refrain from saying thatyou’re
having this problem, too. I assure you we’re actively working on a
fix.
This statement was taken from Chromium ticket #335248.
Okay here’s the solution you can do without changing your theme, right click on my computer, go to your System Properties, and then go to "Advanced", click on "Settings" under Performance, then check the below radio button. This seems to stop it
If the aero fix isn't working for you, download Chrome Beta
I have had this same issue with Chrome 32 (there are so many problems in the dev tools...) but it ONLY happens for me when I have the dev tools detached / undocked from the main browser window.
You might be able to avoid it by re-docking the devtools if you are using them in un-docked mode.
August 6, 2014 - I solved this by installing the latest Chrome Beta https://www.google.com/chrome/browser/beta.html
You can solve this problem in Chrome by following simple steps-
1-Go to Setting
2-Go to Advance Setting
3-Uncheck the "Use Hardware Acceleration when available".
I fixed that problem by linking modem directly to my PC, didn't reinstall or change Chrome or anything. I skipped connection through my wireless router which I think was the problem from the start... now all the pages Chrome couldn't load are loading with no problem at all. Maybe it's time to by a new router...
Can anyone help me figure out why this page causes Android browsers to crash?
http://thewellcommunity.org
All sub-pages seem to work just fine, but when I load the home page on an Android, the browser app just closes without any warning or error messages. I've tried this on 3 Android phones and on a Kindle Fire.
When I completely disable JavaScript in the browser on the phone, the page loads successfully. Unfortunately this is a live website, so I'd prefer to save disabling chunks of JavaScript on the server side as a last resort.
On a side note, Opera Mini, Opera Mobile and Firefox on an Android phone do not crash, but Dolphin, Miren and the stock browser do.
UPDATE: It appears that I spoke too soon when I said this was fixed. I was able to reduce how often the browser crashes, but it still does occasionally crash when the page is loaded. :(
UPDATE #2: It now appears that the crash may be CSS related. After spending weeks enabling and disabling various JavaScript snippits, I tried disabling the stylesheet, and now I can't get it to crash.
Anyone know of an Android CSS bug that might be causing this? My guess is that it's related to some CSS that only gets accessed after the JavaScript does it's work.
I found the culprit... It appears that a css font-family rule was to blame. Although, I'm not sure why since the same font stack is used several other places on the site. :\
Here's the line that caused the problem...
.Site-Search .Buttons input
{
...
font-family: TeXGyreHerosRegular, Arial, "Helvetica Neue", Helvetica, sans-serif;
...
}
For whatever reason that line caused all stock Android browsers to crash. Weird.
Check out Weinre. An explanation can be seen in this youtube movie.
That way you can debug the Android webkit browser just like the well known Firebug.
In Eclipse's emulator (2.3) it loads fine but has some layout flaws.
If anyone came here looking for a possible reason why all of their mobile's different browsers crash after a several seconds when loading a particular website it may be due to the version of jQuery employed.
For example, the LG-p690f and HTC Incredible S are some of several Android 2.3.x phones known to have troubles with fade transitions in jQuery 1.8.1 and 1.8.2 due to a browser javascript bug that will cause jQuery's Animation function to fail at this line:
percent = 1 - ( remaining / animation.duration || 0 )
If you are the owner of the website you can try upgrading to 1.8.3 (or downgrading to 1.7.x if allowed). Otherwise, you can send an e-mail to the website.
Sources:
http://bugs.jquery.com/ticket/12497
https://github.com/jquery/jquery/pull/1019
Apologies but this is not a programming question, but it may have a programming answer.
For some reason my site, http://pctools.alwinsights.com will not display properly in IE (I'm using version 8) but it's fine in firefox and chrome. The content does not appear in the centre of the screen in IE and also generates two JS error messages while the pages are loading.
I've tried enabling Active X and Scripts in the security settings but with no joy. I've also looked around the net but cannot find an answer, well not one that works!
Unfortunately I know nothing about javascript so really don't know where to start with the error messages that are generated.
Any help appreciated.
regards
Nigel
Update:
OK initial error has gone, I'd screwed up with a directory name - apologies.
I've found out that if I disable the option to display the last twitter feed in the wordpress theme it loads OK. So it is the JS code in a php script called thememx-document.js that is causing the error. The code generating the error is "var twitterHtml = jQuery.cookie(twitterCookieName);" It says it's charcater 4, which is a space but I don't understand this.
I can live without Twitter on this site but it still leaves issues as to why content isn't centred nor the pop-up ad is not showing (compare to Firefox) but this may not be a programming issue that warrants a question on this site.
Thanks to all for your comments and input.
Nigel
Start with valid code; a validator will pick up lots of problems. Among yours is content before the Doctype, which triggers quirks mode. Quirks mode causes browsers to emulate bugs in ancient browsers and become much more inconsistent with each other. One of the emulated bugs in Internet Explorer breaks standard centring techniques.
for not properly disply-- its the problem of CSS ...IE7 and IE8 dosen't support css3.so you should simply make another css stylesheet for IE and call it on page only if someone visit your site using IE. and for other broswers it will show exiting style.
and abot JS error --you should check all your php coding and then fix it. its not JS problem. if you are not familar with PHP coding then i am here to offer my free service to you or anyone else. i will help you as i can.
First, having problems with any version of IE is expected and the norm. IE is the worst browser on the planet.
You have a link element on your first line. Links belong inside the head element. Placing it on the first line throws IE into 'quirks mode' and then IE becomes even worse than it normally is.
Good.
OK, maybe your site has to work for IE. 9 times out of 10, the problem is a terminal comma. The following is understood in real browsers but generates an unintelligible error in IE:
var x = [ 1, 2, 3, ];
The tenth time (in my experience), it's string indexing.
var x = "abc";
var c = x[2];
In a real browser, c is set to "c"; in IE, another unhelpful error message.
If this helps, remember: in IE, it's very important to create as many circular dependencies as possible. That is, attach to DOM elements JavaScript functions that have references to other DOM elements. IE fails to clean up such dependencies when the user leaves your site and so leaks memory. Once it leaks enough memory, IE slows and eventually freezes the OS and the user learns a valuable lesson: don't use IE. (Microsoft has a good page explaining how to do this although, inexplicably, they recommend against doing it.)
I'm working on a file upload utility based on Valum's Ajax-Uploader. The idea is similar to the Gmail attachment process. The user should be able to drag a file from the desktop into the browser window and onto the file upload area to get it to upload. This works fine in the browsers that support this functionality (Firefox 3.6+, Chrome 7+).
The problem I'm running into are the styles that should be re-drawn when the user:
Drags the file anywhere in the browser
Drags the file into the upload area
I have tested in the exact same browser versions on WinXP, Vista, and Win7. The appropriate styles are redrawn. However, in Windows Server 2003, they do not.
In Win2003, when I inspect the div that should be redrawn via Firebug, the "drop-area" and "drop-area-active" classes are applied correctly. Firebug even shows the correct style declarations, but the changes are never visible.
The only difference between FF and Chrome that I'm able to spot is that in Chrome, the "drop-area-active" style is displayed for a split second when the user drops the file.
I'm not positive that it is a Windows2003 issue, but that's the only OS in which I'm able to recreate the bug.
Edit:
If you're running Win2k3, try the Gmail drag'n'drop functionality. I can see the alternate styles in other OS's, but not Win2k3.
Edit #2:
Still seeing this issue in many different places. Anyone have any suggestions? I have submitted this as a bug to the Chromium Project. Issue 68632.
http://code.google.com/p/chromium/issues/detail?id=68632