The extension source code is at https://github.com/n8chz/prostetnic-chrome
It works on both Chromium and Firefox, but on Firefox the popup has fixed dimensions, so instead of having the popup grow as the script adds content to the popup, a vertical scrollbar appears, allowing me to view the content, but it's a bit of a speed bump that I'd be happier without. Apparently auto-resizing is a built-in feature of BrowserAction popups in Chrome.
The BrowserAction is declared in manifest.json as follows:
"browser_action": {
"default_icon": {
"19": "search19.png",
"38": "search.png"
},
"default_title": "Search for words in previous highlights",
"default_popup": "popup.html"
},
Are there perhaps any hidden instantiation options other than the ones in the documentation?
One thing that helps (but produces a different effect from in Chrome) is adding style="height: 600px" to the popup's <html> element. Anything 601px or larger results in a popup with a vertical scrollbar.
There are no hidden options other than what is in the docs. This is a known bug which can be tracked at following site. Doesn't work in FF50.0a2 yet.
Bug 1215025 - Popup size does not respond to content change.
Target Milestone: mozilla50
https://bugzilla.mozilla.org/show_bug.cgi?id=1215025
Related
I noticed recently that every webpage I visit on iOS Chrome has an enormous blank space at the bottom of the page. The space is roughly equal to a full screen height (i.e. 100vh) and is located below all visible elements on the page. Basically I can keep scrolling the page until it's completely blank. The scrollbar also shows that the pages are much longer than their content would require.
All the pages I looked at behave fine on Android, on OSX, and even on iOS when I use Firefox or Safari. The issue seems specific to iOS Chrome. I'm not sure when this issue started but I've updated Chrome and it persists.
Is anyone else experiencing this iOS Chrome bug? I haven't found any info about it.
I created a dummy test webpage and just kept stripping it down to see what was causing the issue. Eventually I was left with a page containing only <p> tags and very minimal CSS (no positioning properties) but the extra space at page bottom still showed up. By adding a background-color to the <body> I could see that this extra space was within the <body> but there wasn't any element forcing the body to extend.
After much trial and error I discovered that if I disable Chrome's Smooth Scrolling this issue is resolved and all pages behave normally.
Solution: Load chrome://flags and set Smooth Scrolling to disable.
Seems odd that this would be necessary. Anyone know what's going on?
This is likely a Chrome bug (iPad). I also spent a lot of time debugging all the css and my components. End up event google.com it self has that mysterious white space (which is about the height of the content itself.).
6 hours gone, but it's a relieve to know it's nothing got to do with my codes.
iPhone with chrome is fine on my end
To stop the page from scrolling, in both x, and y axis, we use the overflow: hidden; attribute in css.
So if we apply this to the body,
body {
overflow: hidden !important;
}
this should work in your scenario!
Please make sure you have added this meta tag and the same attributes
<meta name="viewport" content="width=device-width,initial-scale=1.0">
And check your body tag CSS, there should not be height: 100vh and check your pages again by clearing browser cache or in the private mode.
I have a web-application which was originally designed to be used from standard desktops and laptops, now I am trying to see if it can work "as is" also on tablets.
I tried it on an iPad 2, and I fould one major problem: the application makes heavy use of dialogs, created using jQuery UI 1.8.22, which are used as "popup", that is, each dialog contains an iframe, and when the content overflows the dialog size the vertical scrollbar appears, but I'm unable to scroll the iframe content 'cause it will always scroll the main page content.
How could this problem be solved? Do you think it is an issue with my application or with the iPad browser itself?
If it can be of any use, I'll post the code which creates the dialogs themselves, for now just let me say that, when navigated using a standard computer, there are absolutely no scrolling problems.
EDIT:
I just created this fiddle http://jsfiddle.net/MLGku/1/ which shows how we create such popups, I tried the fiddle with the iPad and in fact I cannot scroll the iframe content, I'd be very grateful for any help you'd be able to give me.
In the end I've been able to solve the problem by using this snipped of code:
if (/iPhone|iPod|iPad/.test(navigator.userAgent)) {
$('iframe').wrap(function() {
var $this = $(this);
return $('<div />').css({
width: $this.attr('width'),
height: $this.attr('height'),
overflow: 'auto',
'-webkit-overflow-scrolling': 'touch'
});
});
}
The code above was found here: http://home.jejaju.com/play/iframe-scroll.html
I'm using jquery UI to resize a div vertically(I.E. using the n handle). I'm using a helper so it only resizes after the user stops dragging. After a resize is done I call a function which sets dimensions on surrounding elements so they all fit within a container.
This works in both chrome and IE, but in firefox a css property of top is added which blows the div out of the container.
I've tried removing the top value after the fact, which works, but this is kind of a hack and also causes the div to 'jump'.
Is this a bug? Is there a workaround using jquery css html, etc?
To see what I mean check this fiddle and resize the element, if you inspect it in firefox there will a top css property but not in chrome.
Thanks,
Luke
In my opinion it is a bug.
Workaround: if you add a top: 0; to the css rule for #resizable IE, chrome and firefox have the same behavior. Also see the updated example.
=== UPDATE ===
It's a firefox bug. I walked from the jQuery UI resizable method code until the css method of jQuery (main) code to find an answer. At the end of my search I could found that firefox returns for css top value auto for not/static positioned elements, but returns 0px if relative position is set; in both cases top is not defined (they could be set to auto with no difference - it's the default value).
Also see this example.
In the resizable method this result makes the difference (jQuery UI sets the relative position to the DOM element by adding a class). If the bug (which I have reported to mozilla) will be fixed, the behavior of your example in the firefox should be the same as in chrome.
I'll report here if there is something new...
=== UPDATE ===
Now I have a workaround for you:
for the special situation you described set the css position of your resizable element manually to static.
Add to your stylesheets:
#resizable { position: static; }
Also see your updated example.
I have been using JQueryUI for various aspects of my site, and a small tabbed menu set was working well, except in firefox. The image below shows the same code rendered in firefox on top, and IE9 below. Note the gap under the tabs and the (possible?) increase in padding inside the tab. I have removed all my stylesheets from the site (the 2nd image) leaving just the base JQuery UI one, but the gaps still appear, and only in firefox.
The js call is as basic as it can be:
$("#menuTabs").tabs();
It's not often I have display issues where IE is better than firefox... Having removed all the CSS I generated, and made sure there's no styles being applied, I'm at a loss as to where to look next!
If you can offer any suggestions as to what might be causing it, I'd be a happy chappie!
[EDIT]
After scaling back the code as far as I could, and using only 'known good' libraries, it turns out that it is caused by it being in a table cell!
Here's some code you can have a play with! http://jsfiddle.net/XVHTk/
It does however work when "Normalized CSS" is checked, so it could be padding inherited from the cell maybe?
[EDIT #2]
Right.
So.
It turns out that CSS styles applied to a table to remove padding and margins and borders and so forth are not enough. You have to include cellpadding="0" and cellspacing="0" in the table definition otherwise the jQuery tabs have some extra padding around them.
Odd.
jsFiddle with table and no extras: http://jsfiddle.net/XVHTk/1/
jsFiddle with table spacing/padding stripped: http://jsfiddle.net/XVHTk/2/
Why the HTML cell properties are being transferred into the tabs, I have no idea. I'm just happy to have fixed it!
This is caused by a bug in the ui-helper-clearfix class. See ticket #8442 and the associated fix. As you can see from the ticket, this was fixed in 1.10.1. I've created a fiddle showing this working properly with 1.10.1 and using 1.8.x with additional CSS to fix the issue. The latter shows that if you can't upgrade to 1.10.1+ right now, you can just include the following CSS:
.ui-helper-clearfix:after {
border-collapse: collapse;
}
I have a mobile application running Backbone.js and jQuery mobile. Because I have Backbone.js and for performance reasons I have disabled all the JQM routing and transitions. I understand that storing scroll location is a feature available in JQM, but I am unable to utilize that (as far as I know).
I have a list view with a potentially long list of items. When the user taps one on the mobile device, it stores the current scroll position and renders a new view. When the user taps the "back" button, it goes back one in the history.
clickLink: ->
window.lastScroll = $(window).scrollTop()
render: ->
...
if window.lastScroll
$.mobile.silentScroll window.lastScroll
window.lastScroll = undefined
This works as desired on desktop Safari, but when I try it using it on iOS Safari (both simulator and the real thing), there is an issue with the fixed footer navbar.
If the user taps back, the listview is scrolled down as intended, but then if they tap the footer navbar, it is as if they tapped under it, whatever list item is under it will be activated instead. If the user scrolls a little bit before tapping the navbar, everything works fine.
Does anyone have any ideas? Perhaps there is a better approach that would avoid this issue all together.
Thanks in advance for the help.
Could it be related to this bug?
Form elements can lose click hit area in position: fixed containers
(linked from here JQuery Mobile 1.1.0 docs )
I see there is a workaround in the first link - worth a try?
Chad Smith Answered this Mobile Safari bug on fixed positioned button after scrollTop programmatically changed...?
His method worked best for me. Here is his response:
I got around it by adding a 101% high div then (almost) immediately removing it.
Try:
<style>
.iosfix {
height: 101%;
overflow: hidden;
}
</style>
and when you scroll:
window.scrollTo(0, _NEW_SCROLLTOP_);
$('body').append($('<div></div>').addClass('iosfix'));
setTimeout(function() {
$('.iosfix').remove();
}, 500);
It also works with jQuery.scrollTo.
See an example here.