I am using Twitter's Bootstrap 3 modal, and it looks great, except on google chrome (perhaps other broswers too) on OSX, the page underneath jumps left a little bit - probably due to a scrollbar taking some space on the right.
Is there any way to prevent the page jumping when using modal windows on OSX Chrome?
I literally just fixed this problem on my project.
Put this line of code in your css:
body.modal-open {
margin: 0 !important;
}
If the above fix doesn't work for any future readers (as it didn't for me), here's a whole thread detailing potential fixes. Looks like it will be addressed permanently in the next Bootstrap release.
Related
I have created my first microsite with Umbraco/ASP.NET at www.surreyhillsmt.co.uk. I started with a bootstrap theme called Agency from startbootstrap.com, and find that the smooth page scrolling from my menu works on the Edge browser and both Safari and Firefox on an iPhone/iPad.
However, smooth page scrolling does not work on either Firefox or Chrome on a PC (fully updated Windows 10, and both Firefox and Chrome installed within last couple of days). This problem is not exhibited by the static bootstrap theme that I used.
I would really appreciate any help. By way of background I am competent with C# and okay with HTML/CSS. I have zero knowledge of javascript and the like.
This is no longer a problem. Oddly this was fixed with the passage of time. I guess it was a caching related issue.
In my web application I frequently have sections that need to be collapsed/expanded. I do this with jQuery using the slideDown() and slideUp() methods. They work great. However, in Firefox, if I am scrolled all the way to the bottom of the screen and I collapse a div the screen stutters and flashes as the div disappears and the page is automatically resized by the loss of the element.
Has anyone run into this problem before? I've been working around it by setting a min-height with a generous amount of space for any section that will be collapsible but this seems like an unnecessary solution. Chrome doesn't have this problem and, amazingly, neither does Internet Explorer, both of which smoothly resize the page without any sort of stutter or flashing.
I'm using Firefox 3.6 on Ubuntu and I've experienced this problem on earlier versions as well. I have not tested on Firefox 4.
I have ran into this problem before and yes. I have worked around this by setting a mini-height or consider not using a slide effect.
On the mobile site I'm building, I need the top header to stay fixed positioned.
I am aware of the fixed position solution for Mobile Safari as seen here:
http://doctyper.com/archives/200808/fixed-positioning-on-mobile-safari/
I tried it and it works well. However, I was wondering if there's a single solution that works for all major smartphone's mobile browsers. Note: I don't need the footer to stay fixed, just the top header. So this should make it easier accommodating for all mobile screen sizes since I'd be just setting the div's top to 0 onScroll.
Thanks!
Important update
As of iOS 5, fixed positioning works fine on mobile. Similarly latest androids support it.
Old answer
I think iScroll is the most actively developed solution, it does support Android
But there are a few things to watch out for:
By enabling this hack you are disabling features people are used to like zoom.
It is adding a lot of complexity to your solution.
For these reasons JQtouch decided not to use it:
Not a problem. It is not currently
supported in jQTouch. Not sure how
familiar you are, but the main problem
here is that mobile Safari does not
support position: fixed. A few people
have worked on implementations of
this, most notably
Cubiq
and
Doctyper.
Both feel wrong to me,
hence why I don't do by default, but
you're free to try to make an
extension which supports it-
Personally when dealing with stuff that needs fixed positioning on an iPhone I prefer to go with static positioning and just autoscroll to the bottom/top when changing the content dynamically.
I was facing the same problem for more than two weeks . And this solution worked for me. Just include
-webkit-backface-visibility: hidden;
in the css of the element along with position:fixed .
It will work fine
Following on from the link that Sam Saffron posted, it seems that a new version of iScroll (version 4) has resolved some of the problems Sam listed.
iScroll-4
In addition to all previous iScroll features, version 4 introduces:
Pinch / Zoom
Pull up/down to refresh
Improved speed and momentum
Snap to element
Customizable scrollbars
I have only looked at the demos on their site, so I can't vouch for it, but it looks good!
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."
Despite my most convincing cries to the contrary, I was recently forced to implement a horizontal drop-down navigation system, so I opted for the friendliest one I could find - Son of Suckerfish.
I tested in various browsers on my machine and all appeared to be fine. However, some (but not all!) IE7 users are experiencing an issue where sub menus do not close after they have been hovered over. The most annoying thing is that the affected users are using the exact version of IE7 that I am (7.0.5730.13), with the same privacy and security settings (I even had them send screenshots of the tabs in Internet Options) on the same OS (XP). I cannot verify if Vista is affected or not.
Obviously trying to debug this issue is a nightmare since I cannot replicate it, so I am wondering if anyone here can and might know how to solve it. I have set up an example page here:
http://x01.co.uk/menu_test/
Additionally, there's an annoying flicker on rollover of the sub items which I have also tried to solve with no success, so any help with that would also be appreciated.
This is a problem that occurs in IE7 when another part of the page has focus (ie, you clicked somewhere and then mouse-over the menu). It seems to be an issue with the :hover pseudo-class.
Adding a hasLayout trigger to the :hover style should fix the problem.
#nav li:hover {
position: static;
}
There are other solutions too. There's a great write-up about the problem here:
Sticky Sons of Suckerfish
For testing why not download the Vista IE7 VPC image from MS themselves?
http://www.microsoft.com/downloads/details.aspx?FamilyId=21EABB90-958F-4B64-B5F1-73D0A413C8EF
Not sure about the bug though. Remember having similar issues I think its because you need a JS. Will try and find out