Anyone here know the fix for this?
Others have stated that this is a feature and not a bug for safari on iPad - two finger scroll within the frame might do the trick for you? However, would be nice to have some type of visual tip on scroll potential within the frame.
http://discussions.apple.com/thread.jspa?messageID=11612916
chad.
Related
So I really hate the way chrome extension development works so I decided to make a regular webapp and use an iframe in my extension. Everything works fine, except for the dimensions of the website and the scrolling on the extension/site.
When developing the site, I knew I was going to use an iframe so I used percentages when formatting the site, for the most part I used 100% on most divs and textboxes. Anyway, the problem I am facing is that the scroll is extremely wonky on the extension for instance this is a picture of my extension with 400px height:
400x400. Everything looks fine.
and here is my extension with 800px height:
400x800. Scroll appears.
Why is the scroll appearing if I am merely making the extension longer? It doesn't make sense to me.
Any idea why this is happening?
There is a limit on the size of the popup window. I don't know the exact dimensions though.
You cannot increase the size of the document past it, scroll will appear.
I have been looking for this for a while:
There are a ton of ruler extensions for all the common browsers but I can't find one that has a magnifying glass. Can anyone help me out please?
I'm talking about a magnifying glass like the Awesome Color Picker extension in Chrome:
The ruler extensions I've used really hurt my eyes when trying to measure anything to pixel precision.
Any browser is fine with me.
Note #1: This is not about seeing the width of elements through 'inspect element'. I need to find the precise number of pixels between any two points on a web page.
Note #2: Zooming in the browser doesn't do it either because some of the pixels change when I zoom.
Thanks in advance!
I am not sure if this is what you were looking for, but it might be worth checking out. It has zooming in on pixels, up to 3200%.
http://matthiasschuetz.com/pixelzoomer/
It's a FireFox add-on. I am not affiliated with the add-on at all.
Check out xScope from IconFactory. http://xscopeapp.com I use it all the time for development layouts. It's got several tools, including rulers, guides, a tool for dynamically measuring elements, and a loupe for viewing an enlarged part of your layouts. It's not a browser plugin, but I find that this makes it actually MORE useful.
As of right now I have a View with a UIWebView inside of it and some added custom gestures. Some examples of these gesture are Two Finger Slide Right to Go Back, Two Finger Slide Left to Go Forward, Two Finger Long Press for Refresh, ect.. But now I'm facing an issue I knew I would have to face when I began developing this app:
All of the gestures work great unless the UIWebView is zoomed in. Even if it is zoomed in the tiniest bit (or you are able to scroll the web page horizontally), the gestures that require you to swipe left or right are suddenly disabled because UIWebView takes first priority over these gestures.
If anyone can shine some light on this issue or even provide a work-around, I would be very grateful. Thanks!
I'm more familiar with OS X, but could you subclass UIWebView to remove this behavior?
For some reason i am not able to enter any text in inputtext in dhtml environment. The same is working fine in swf10 environment.
When i hover over the input text i observed that the cursor is not changing to selector. It looks as if the onmouseover event of inputtext is not getting fired.
Has anyone come across this kind of issue in openlaszlo dhtml envrironment?
I am using OpenLaszlo 4.9, Windows 7 and the browser is Firefox 15.0
I found a bug report in jira http://jira.openlaszlo.org/jira/browse/LPP-9934.
Please suggest any ideas to overcome this issue/
The problem you are seeing is probably connected to the way OpenLaszlo replicates the behavior of clicking through Sprites or visual elements in the Flash runtime for the DHTML/JavaScript runtime. Until recently browsers didn't support that kind of functionality directly. Therefore the OpenLaszlo team had to use a workaround, which is described in detail in this comment on LPP-5447.
Clickdivs exist to have independent control over clickable sprites,
without interference from regular divs. They are placed in a separate
copy of the regular lzdiv sprite hierarchy so we have more control.
This also provides a place to put focused inputtext divs so they are
in the foreground and clicking/dragging to edit works properly.
The clickdiv functionality seems to be broken from time to time with browser updates or due to regressions. In 2012 some improvements to the DHTML runtime click-through functionality were done, using newer browser features in Firefox (which now allows to click through div elements using the CSS style pointer-events). Since the clickdiv functionality is part of the LFC, fixing that functionality in your application is not advised.
You can test if the inputtext works by tabbing through the components until your inputtext element has the focus and start typing. If the text can be entered as expected, but you cannot click the component with your mouse to select it, it's definitely a clickdiv problem.
Update: Tested with OpenLaszlo 4.9.0 and various browsers
I've tested with OpenLaszlo 4.9.0, DHTML runtime and IE9, Firefox as well as Chrome, using the test case attached to LPP-9934: All browsers show that specific bug behavior. If the bug has not been filed, please file a JIRA bug.
I have just created a dropdown for my site. It works fine in all other browsers except new version of opera that is 12.02.
Webiste Url : http://www.sktechnologyworld.com/demo/anything/
Here when you mouse over on "Categories", it displays dropdown of that categories then when you hover on categories then it displays subcategories of that category. At this time there is background line remains at top of that perticular category and this same thing in all the subcategories. However when i open dragon fly in opera by pressing ctrl+shift+I then it works fine but if dragon fly is not open then it makes it weird.
Its very strange and have not face this kind of problem before. Any help?
Thanks
This is indeed a bug in Opera. As it's merely a cosmetic issue with no big impact on functionality I suggest you just report a bug to Opera Software and forget about it until it's fixed :-)
The root cause is that Opera fails to draw the background colour of the padding-top of the A elements correctly. It's mainly triggered by the padding-top:9px instruction on #CategoriesBar .nav. However, trying to work around it means adding hacks to your CSS and that makes it harder to understand and maintain - even more likely to break in future browsers. Hence reporting a bug and not trying to work around it is your best way ahead.
Here is a simplified demo you can refer to when reporting the bug:
http://jsfiddle.net/sNHbB/
Please let me know the bug reference number and I'll give it a kick for you.