I am developing a firefox os app which has a single html page. Different sections of app are created as divisions with 100% width and height with fixed position and with different z-index values(It is created like one division over the other). It is running just fine on browser and of course the firefox os simulator. But in my firefox os device (Spice MIFX1) the app is fine but when we maximize our app after minimizing by pressing the "o" button, may be due to low specification of the device we can see the different divisions getting stacked one over the other which may affect the app perfection and user experience. The app will then run just fine but I don't want the user to see the divisions getting stacked. This problem is not there in the simulator or in the browser may be because it is running faster in my laptop. Is there a way to avoid this weird scene of getting stacked? Maybe something which can hide this stacking process? I think this is happening due to the slow execution of the script which is a part of the Firefox OS (The script to be run when the app window is maximized) because during maximizing I don't have any scripts to be executed in my app. What is the right procedure to avoid this problem due to poor hardware specifications?
Would setting element.style.display = "none"; be useful to set on all "divisions" that weren't currently being shown? That way only the top would be shown? This might leave the screen white as the other divisions are being added then composited. Also, I'm curious if it would be more performant to completely remove unshown divisions from the DOM, and only add the shown division to the DOM, ever. This might not work if you need multiple divisions to be shown at once (but I'm not sure what your UI/UX looks like).
Related
I am having performance and "jank" issues while scrolling on a Android React Native app. The JS FPS drops from ~60fps down to ~3-10fps while scrolling.
The content being scrolled DOES include images containing transparency and text layered over images. If I remove the images, performance increases significantly.
The above scenario sounds like a perfect case for renderToHardwareTextureAndroid. That said, enabling this property on a View containing the images/text seems to have no effect at all.
How can I confirm this feature is truly turned on and working as expected? Is it possible that something I am doing/not doing is forcing the hardware rendering to not take place?
Is there a way to detect if an application (say a chat client or msword) is on top of my browser window.
One way is to check for focus. But that does not absolutely say that another program is on top of the "view-able" area of the browser with respect to complete screen.
What if the complete browser is viewable but the focus is on the word document/chat client.
Edit:
Found a sample demo from a company which does this http://www.spider.io/vStp83jg6/
I don't think this requires flash or any plugin, in order to be effective this has to be based on CSS and Javascript.
The security sandbox of the browser prevents accessing this information from the operating system.
The only thing that they can be doing consistently across browsers is to detect some sort of side effect of the fact that the browser window is hidden by another window.
One of the side effects that can be detected is if browser rendering optimizations for painting elements have kicked in or not.
According to the spider.io viewability video, they are already detecting if an add is visible based on browser rendering optimizations detection.
If an add is not visible, then for that section of the page rendering optimizations kick in and the rendering of that section of the page will become slower, in order to save memory and CPU resources, and speed up the rendering of the visible portion of the page.
This same technique could be used to detect if a browser window is hidden or not.
If they detect that rendering optimizations are ongoing in several regions like the 4 corners of the visible viewport and the center of the page they can safely assume that the app is hidden by another external app, or calculate an estimation for the percentage overlap.
They don't say how they do it in detail, but as it's based on speed measurements it might be something like this:
One way that could be used for detecting if another window is hiding the browser:
Create a small invisible CSS3 or Javascript based animation that animates invisible elements in different parts of the page. The animations should not affect the performance of the page and can be started/stopped at will.
Measure the timings of the animation at page startup, and take an average. If the page get's hidden by another OS window, then the rendering optimizations kick in and the time that the animation takes to run is longer.
Check here a browser API to detect the start and stop of CSS3 animations, this could be a way to implement this.
Commercial web traffic data harvested by company such as Alexa. Is performed by installed software, such as toolbars. And tracks the users activity, programs, windows open.... everything... (with consent)
Controversial answer, it does the above without consent (spyware?)
Note the key point of the above 2 method. is that the data comes from a sample of computers in which the software is installed. Not every visitor of the site (unless visiting the site inserts the spyware)
By having custom software installed. They can get around all the respective browser related restrictions / security.
Perhaps more can be found by providing information on the companies that claim to do this?
I'm new to the HTML\CSS\Javascript thing, so please excuse my incompetence. I know for some bits (mainly class modification) I'm not using jQuery, but only because I couldn't get it to work, so I went old-skool.
I have a web page (here: http://dashboards.kantarhealthspain.com/uk/segmentation/Segmentation_v0.4.html) that works just fine in Chrome (and Safari) on my desktop. You click on the massive squares in the middle of the page, and then click on the >> to go to the next 'page'. Eventually you get to the point where it hides\unhides one of 4 segments based on what you've chosen. It's a bit clunky, but it works, which right now is a win...
When I view the same page on an iPad, the layout isn't quite as good, but that's not my problem. When you get to the final question to show\hide the segments, it seems to change the way the whole page is rendered - every element seems to take up so much room.
Debugging on an iPad is very difficult, as I'm using a Windows machine to develop, and the Safari emulator doesn't actually emulate what's going on, as it doesn't break on desktop Safari (for Windows).
I don't even know where to start looking on this - any hints would be much appreciated.
EDIT: Now I've fixed the evil HTML, it looks like when the divs at the bottom are shown\hidden, the height of each div above doubles(?) I've made the background of NavDiv and Breaker fuschia and maroon so they show up, and the double in size. The height is a percentage of the size of the page (I presume) - what's going on there?! Does the percentage recalculate when areas are unhidden?
Thanks
Tom
We have PrimeFaces 3.4 application that was working very fine until it was tested under firefox. However, after going to test, the problems have arised:
Application will be launched in IE only (IE 9)
Application is launched inside frameset
We are using p:autocomplete in many places, that includes dialogs. The panels for those autocompletes are usually not displayed after click when:
Running inside frameset (rarely happens in normal mode)
IE developers tools are closed (rarely happens when they are opened, making the bug hard to debug)
The browser window is not maximized
The last thing is the key from our observations. The solution is to either maximize browser (which can work because we have big screens) or to zoom out the content. Therefore, I suspect that it's the issue with calculating the position where the autocomplete panel must be displayed. The algorithm must take into account several conditions, such as if the parent is positioned (dialog: position fixed), if there is scroll, whan is the offset - here the frames could mess up some things.
However, debugging is hardly an option, first because there is no official non-minimized primefaces.js, second because opening the IE developers tools somehow stops the error from occuring.
Under those circumstances, I ask how the autocomplete can behave such way, and how it can be affected by any of the elements of the puzzle: frameset, dialog, IE development tools?
Related with: IE8 and Primefaces p:selectOneMenu misbehave when having a lots of p:selectOneMenu in a form
The problem is that PrimeFaces relies on visibility:hidden to make a lot of dimension calculations. When the invisible components were out of page bounds, IE wasn't calculating dimensions as supposed. I haven't gone into details of PrimeFaces rendering engine, but simply activating always scroll solved the problem:
body { overflow-y:scroll; }
This answers the question why the problem was often seen when the frameset was used (less place) or why maximizing browser was helping.
I am trying to debug this and can't make any headway. I've got this HTML5 JavaScript library I am building and the test page for it can contain large volumes of output as I am piping console.log and exceptions out into the DOM to quickly inspect them on mobile devices (it is the only way I know of inspecting state on an Android device for instance)
Here is the page. So long as I don't push up broken code while I work on this you should be able to produce plenty of debug output which will be pumped into the <body> thus allowing the page to scroll. Note also to toggle the visibility of the big blue debug panel you can tap the header text at the top of the page (like a button).
The issue is specific to iOS: Tapping the iOS status bar does not work in either portrait or landscape modes, and I am not sure what it is I have done with JS or otherwise that has disabled this quite handy feature.
Use of -webkit-overflow-scrolling: touch appears to be the culprit for iOS6 here. It actually looks like iOS5 is less broken w.r.t. this issue.
I think there may be a way to work around the issue by dynamically setting -webkit-overflow-scrolling: touch on the elements that need it by catching touch events on them. Or just leave it off as they still remain usable (just have no momentum).