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.
Related
This is really curious. Interacting with select inputs seems to hide/show address bar based on 'perceived scrolling' by the browser.
I understand the behavior for normal content related page scroll, but it doesn't make sense for the address bar to hide/show based on scroll direction when a select input is being interacted with. This is on ios 15.x and while the example below is on an emulator, the original 'bug' was caught on an actual ios device.
Changing scroll position via JS seemingly does nothing in this case, nor does updating overscroll-behavior or touch-action css attributes on the dom elements.
Here's the behavior in question:
Looks like it is a bug in the iOS 15+ on Safari. There is no issue like that on Chrome.
Nevertheless I've found a workaround for this.
I've made an example, you can test it here. Just open the link on your iOS device. You can find a git repository with the example on my GitHub.
It is not a good practice, it is just a workaround, so there is your choice whether use it or not.
Also, just for your information: I've discussed with other developers who close to me and we have agreed that it is not very good practise to have scrollable element inside scrollable page. On other platforms also might happen some not predictable glitches. it is better to have another UI elements for that if possible.
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).
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).
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
This may sound crazy, and i didnt believe it until i saw it for myself.
The vertical scroll bar does not scroll when you click in the space between the scroller or the arrows. You have to drag the bar to get it to scroll. This only happens in the ugly default theme (not windows classic).
The scroll bar has some heavy javascript behind it that drive scrolling of another DIV on the page.
Has anyone even encountered this before? Why the heck does the theme influence IE's rendering?! Only IE!
edit:
this problem happens when you are in "non-classic" XP theme (the default ugly one). switching themes does not cause this, but it does fix it if you switch to classic from the default.
Does it help when you add
<!--[if IE]><meta http-equiv="MSThemeCompatible" content="no"><![endif]-->
to your page source? It worked well to work around glitches in IE when a non-classic theme is enabled for me. Note that the conditional comments are there so that firefox does not parse the tag (because it will screw up scrollbars in firefox sometimes).
I just had the same problem with vertical scrollbar in IE7 within the XP theme. After many experiments, I finally found the solution to it. I don't know this solution fits your case.
The container (div#scroll in the example below) with the rendered scrollbars must be larger than 18px. Any number below that will cause the vertical bar disabled.
<div id="scroll">
<div id="fill">
</div>
</div>
The stylesheet, for example:
#fill{
width: 1px;
height: 1000px;
}
#scroll {
width: 18px; /* This has to be larger than or equal to 18. */
height: 50px;
overflow-y: scroll;
}
Thanks,
Grace
In order to avoid certain Windows restrictions, IE re-implements almost all the controls visible on a web page.
The Old New Thing : Windowless controls are not magic
<excerpt>
The Internet Explorer team went and reimplemented all of the controls that a web page would need. They have their own windowless checkbox control, a windowless listbox control,
a windowless edit box, and so on. In addition to reproducing all the functionality of the windowed controls, the Internet Explorer folks also had to reproduce the "look" of the
windowed controls, down to the last pixel. (Functions like
DrawThemeBackground and DrawFrameControl prove extremely helpful here.)
If I recall correctly, the only element that is still windowed is the <SELECT> element.
If you squint, you can see some places where they didn't quite nail it. For example, if you right-click in a text box, options like "Right to left reading order" and "Insert Unicode control character" are missing. As another example, notice that IE's scroll bars do not light up when you hover over them.
</excerpt>
Without seeing the code implementing your page, I would guess that this is another manifestation of "IE's controls don't act native".
If you have a support contract with Microsoft, I'd suggest complaining to them through that channel; if not, see if you get any responses in the microsoft.public.internetexplorer.general newsgroup. Back in IE6, they broke the scrollbar with KB824145 and fixed it with KB832894, so it's not like theses sorts of problems haven't happened and been resolved before.
First, I'll start saying that IE is a terrible browser and in some cases you don't have control over issues while developing a web application.
In that case I haven't encounter such an issue and a Google search don't pull anything on the subject. I'd say it must be something in your code that lead to a weird bug. Most likely it won't break in a lot of systems, so unless it's a very important application (sales, government...) you could leave it that way.
Look at it that way: who change the style of windows to classic? Geeks. And do geeks use IE? No. ^^ ... Joking, but not really.
If it's important I'll need to take a look at your actual code for "The scroll bar has some heavy javascript behind it that drive scrolling of another DIV on the page."