I have a site that I've implemented flexpaper on and it's working beautifully, or so i thought. I had a user email me yesterday because she was trying to view a document and couldn't because it was so small.
Turns out when flexpaper loaded the document in, it set the zoom to -3%, I don;t know if she realized it and was just complaining about the fact that it loaded that way, or genuinely thought it was broken. Changing the zoom is easy enough, but rather annoying to have to do it every time you load a document.
I don't know if it had the same behavior in IE, but she had this problem in firefox. On both my machine, co-workers machines, and her co-workers machines, it works fine, but we are all running vista and 7. Once we loaded up an XP machine, the zoom problem showed itself.
I know there's a zoom function in the API so I can hard set the zoom, but I'm interested to know if anyone else has come across this and if anyone knows what the cause is. I would like to fix it if it's something that can be fixed.
Never figured out why it did this, but changing the zoom settings, setting fitwidthonload to false and scale to 1 made it work just fine.
Related
I really hope this is a case of can't see the wood for the trees, because I just can't believe my own eyes at the moment! If you look at the image below you'll see my mouse pointer is hovering over a an IMG tag in the Chrome Debugger/Inspect Elements tab, and the handy tool-tip in the mobile display is usefully showing "img 45 x 40" exactly where my hg.png image should be rendering. Yet Hansel and Gretal are still stuck where they were before the: -
HandG.setPosition(path[currStep]);
See https://github.com/RichardMaher/Brotkrumen/blob/master/HandleMap.js line# 321 for complete example.
How can this possibly be? When can the SRC attribute completely divorce itself from its IMG tag?
This didn't used to happen a few years ago (trust me :-) Has there been some optimization in Chrome? Buffering Map Marker moves? Can I turn this behaviour off?
The "optimize" marker option is set to false. Anyway surely we can just forget Google Maps here, this is just a basic HTML DOM issue right?
NB: PLEASE keep your opinions on the wisdom or otherwise of relying on how Google Maps renders markers. I consider myself suitably chastised and if you have a better way to smoothly transition markers from point to point over a set period of time then please mail me directly. What I'm asking is what witchcraft (my destination marker is a itches hat :-) is at work here.
Edit 1
I'll investigate the FF debugging options but am really leaning towards a novel Google Map optimization because the first leg of the trip completes as expected but then my polygon.setPath and my marker.setPosition calls don't take effect progressively. The marker(img) moves after 2 more legs (then on the final leg) and no further path is plotted till the last leg completes.
Edit 2
Please Note: - The https://github.com/RichardMaher/Brotkrumen repository can be cloned by anyone! Just stick it in a internet facing folder/directory and go for "https://your.domain/TravelManager.html" You'll need a Google Maps API key to use the maps and at least a couple of GPS readings before you can press "Arrive".
Thanks to #Bravo I ran it on FireFox(1) and got a slightly more illuminating response. It does now look like a coding issue (event race condition or some such) as the pattern displayed was: -
The first leg (as with Chrome) Transitioned from A to B in correct time.
The second leg was skipped then HandG floated up to the third geolocation position but with what appeared to be a combined duration?
Likewise, the 4th leg was not visible but the 5th was peachy.
Unlike Chrome the progressive path was in sync with the marker.
So, yes, it looks like my code is firing 2 events before the browser can give me a Transition and acompanying transitionEnd.
(1) I have work to do on FF asthetic compatibility :-( also (I'm not asking you to teach me FF debug) with Chrome remote USB debugging I get to enter the URL on my PC and it appears in the phone's browser. I can then unplug it, go for a walk around the block, connect it back to the USB again, press "inspect" and have full debug sesion going. On FF I just entered http://localhost:1234 into the phone browser and it activated but I couldn't see how to get a debug session happening.
Please feel free to delete the question because, as pointed out by #Bravo, it is a red-herring :-(
The only take-away is: - There are now at least two of us who now strongly recommend using FireFox to debug youre mobile Web Apps and avoid Chrome!
Once I could believe my eyes again, I realized I was getting 2 transitions for my marker reposition. Property Height, Width;
It is with hand on heart that I tell you that several years ago I only got one transition for the multi-property but that's neither here nor there. We are where we are.
Thanks again to https://stackoverflow.com/users/10549313/bravo
I ran into a bug that seems very nuanced and strange. I am using OpenLayers (v4.0.1) in a web application to display multiple WMS layers from a GeoServer (v2.8.2). Everything seemed to be working great until Windows 10 did a big update. Shortly thereafter, my browser began to crash when attempting to view the page on which the map and all of its layers should be displayed.
After a lot of digging, it appeared that this issue only shows up in Chrome Version 60 (60.0.3112.90 to be exact). I tried to reproduce the issue on multiple OS's and browser combinations (Linux/Windows/Mac and Firefox/IE/Edge/Chrome Version 59) and it works great everywhere except on Chrome 60 (across all OS's).
Though still hard to pin-point exactly, when doing a step-through of the JavaScript to find where the hang-up occurs, it is definitely happening somewhere inside of the OpenLayers code. Another key discovery is that the error does not occur at all if the browser window size is "small" enough. In other words, if I resize my window and try again, it will suddenly work consistently once a somewhat-random-seeming, certain browser size is reached. It seems to be more area-dependent, though, than a specific height/width constraint, as various height/width combinations will either work or not work.
At this point I have no great idea on how to resolve this issue, so I'm starting here by simply wondering if anyone knows if it would make sense that something in Chrome 60 is changing the behavior of the OpenLayers JavaScript library? If so, I'd want to open up an official GitHub issue with them. If not, would it be a Chrome issue I'd report? I'm reluctant to believe it is something that I have programmed, as it works in every other browser.
Thoughts?
This does indeed sound like a Chrome bug. Please file a bug at crbug.com/new, and include:
repro instructions (ideally, a link to a site that will trigger the crash)
any crash reports you see in chrome://crashes (if this is what caused them)
If you post the bug number here, I'll make sure it gets looked at. Thanks!
Folks -
Longtime lurker, first time poster. I've found many answers here in the past, and have always appreciated the expertise. I'm a bit of a noob, so bear with me:
I have a landing page. It displays well in Chrome, Firefox, Safari, and older versions of IE. All of the above include the the Google ReCaptcha - no issues, widgets work, etc.
IE 11 turns this to mush. My graphic fails to load, and it seems the recaptcha moves itself to the full width of the page instead of the small part I've intended.
Oddly enough, if I grab the sides of the browser window and adjust the width in any way (wider or narrower) the image snaps in where it should be, and the page looks perfect. Likewise, if I inspect the element, the page loads exactly as intended.
This seems like it should mean something to me, but my knowledge is too limited to get exactly what I'm being told. Can anyone shed some light on this for me?
I can furnish source code and screenshots if that's required.
Regards, Cheers, and thanks for any thoughts -
CDM
#Romulo helped me tremendously with this issue. The entire page was being loaded by a script, and there were errors within the script itself that needed correcting. The solution required a style block to be moved, which solved the issue. This was probably a once-in-a-lifetime issue, but if you find this page and think this might be what you're dealing with, feel free to message me and I'll be happy to discuss further.
I have a problem where Mobile Safari crashes when loading and manipulating the DOM with jQuery when the pages get too big.
I get the same problem on both iPhone and iPad.
What are the best way to troubleshoot mobile pages to find the error? Are there any known problems that might crash Mobile Safari?
I actually found the problem. It wasn't with JS as I thought, but with the CSS. I added class to make a CSS transition to fade in some elements. For anonymous users these elements had display: none; and probably never ran the opacity transition.
The strange thing is that the transitions was on exactly two elements. So why would this only crash on long threads with 100+ comments?
So the bottom line is: -webkit-transition crashed the page on mobile safari.
Had the same issue, for me it was -webkit-transform: translateZ(0); that caused the crash of Safari.
I know this question has been successfully answered but I just wanted to put my five cents in too as I have been banging my head against the wall over this one quite a few times:
As most answers have pointed out already it usually comes down to memory issues. Almost anything can be the last bit that finally tips over the "memory pile" much like a translateZ or anything else.
However in my experience it has nothing to do with the actual CSS (or JS) command in specific. It just happens to be that the last transition was one too much.
What tends to help me a lot is to keep anything that is not visible at this time under display: none. This might sound primitive but actually does the trick. It's a simple way to tell the renderer of the browser that you don't need this element at this time and therefore releases memory. This allows you to create mile long vertical scrollers with all sorts of 3d effects as long as you hide elements that you are not using at this time.
The main issue with any iOS app is memory usage. So, it is likely that your pages are using too much memory.
Mobile Safari use some clever technique so that not the whole page has to reside in memory at any given time, only a portion of it. Maybe you could check if anything in your page defeats this mechanism or makes it less effective.
In any case, to give more up to the point suggestions, more information about your page would be really great.
By the way, you could have some hints from the crash log that the device store. Check to see if you can find it under Settings:
General
About
Diagnostics & Usage
Diagnostics & Usage Data
If it's a memory problem, you should find something like "signal (0)"; not sure if this can only mean "killed due to memory usage", but I usually take this for granted when I found a signal (0).
Otherwise, it might tell you what is wrong...
Hope this helps.
There are both memory limits and Javascript execution time limits, though it's a little fuzzy as to how you may actually hit those. Common reports come in that a page with a size greater than 10MB will have issues, and Javascript execution is limited to 10 seconds.
See Apple's documentation for more info.
I recently had an issue with mobile safari crashing on web-app pages containing a lot of images (30+ were enough) and a few transformations for the menu. After a lot of trial and error, I settled with a solution similar to what LinkedIn does, but for infinite scrolling using angularjs. I used requestAnimFrame and two expanding/shrinking divs (with js style attributes) on the top and bottom of the list to remove all image containers (with other stuff overlayed on top) except for a few ones which are close to the viewport. Scrolling performance (native, no js) is fine and memory consumption is in check.
I had a similar problem, the web page worked like a charm on android devices and crashed on IOS (iphone and simulator).
After a lot of research (using also the ios_webkit_debug_proxy) I found that the problem was connected to the jQuery ready event.
Adding a little timeout solved the problem. My application was also using iframes.
$(document).ready(function () {
window.setTimeout(function () { ready(); }, 10);
});
There is a page that uses PHP to fetch search results from Google Search API and then it puts the results on the page some funny way in a circle. The code may look crappy but seems that it works more or less fine in Firefox. When you enter a search query and click submit button or Next/Previous links, it fills the wheel with results. The problem is its work in IE. It works there very slowly and then it doesn't clear the wheel before filling in new data, but puts it over that. My friend asked me to help him with this code. Please give me a piece of advice how I can fix it. Thanks so much!
Raphael runs very slowly under IE documented here.
As I understand it, VML itself in IE is fast enough, but the Raphael layer has some inefficiency.
I see you're using Raphael.js, which renders vector in VML/SVG (depending on browser). IE8 has degraded support for VML, unfortunately, and I hear it's also quite a bit slower than IE7. BTW, in IE7 it's kinda funny looking.
In terms of Raphael, it may be something as simple as resetting some context, I'm not sure. I've looked at Raphael before, but never used it.