I am facing a problem very similar to what was reported and resolved in this SO Question: iOS 11 Safari bootstrap modal text area outside of cursor
. However, the difference for me is that I am using Aurelia & Semantic UI.
I have tried using position: fixed in ux-dialog-body as described in several fixes for the problem occuring in bootstrap (in those examples to be added to the body of the modal), however that did not work.
I would appreciate any help on this issue, thanks in advance.
So I got the idea for the fix here : Semantic-Org/Semantic-UI-React
Basically the problem relates to the height of the content behind the modal/what the modal is lying on top of. So, hide all of it when opening the Modal and put it back when done. However, only for iOS, because for some reason on our site doing otherwise breaks Android devices.
iOS: boolean = !!navigator.platform && /iPad|iPhone|iPod/.test(navigator.platform);
In opening the modal
if (this.iOS) {
$('body > :not(ux-dialog)').hide();
$("ux-dialog").show();
}
And closing
if (this.iOS) {
$('body > :not(ux-dialog)').show();
$("ux-dialog").hide();
$("ux-dialog-overlay").hide();
$("ux-dialog-container").hide();
}
I hope this helps someone else.
Related
I used the latest Vaadin Start page to generate an app skeleton (Vaadin 21 / Java 11)
It works so far, I used hybrid mode with various views.
When clicking view links in the menu only TS+HTML based views will register in the GUI as selected and get a colored "selected/active" styling.
When I generate an app which only has Flow views, the first view will be stuck with the selected styling, but other views will register properly when clicked.
Only when I generate an app which only has Fusion views, all view selects will properly register.
I guess this is a bug?
Edit: video of the behavior when in hybrid mode. The menu item names correspond to the type of view which is being selected. As you can see only fusion views show the "select" in the menu:
Edit2: I think the problem is caused here:
?highlight=${viewRoute.path == appStore.location
Seems like the appStore.location is not being set from non-Fusion views. I put a console.log in the index.ts eventListener and non-Fusion views all just pass "(.*)" as the view name/location, which is the reasion why this fails.
So the #Route(value = "view-name") declaration in the java-class seems not to be passed properly at the moment.
BR
Daniel
This seems to be a bug in the Start project templates. I added an issue in our internal issue tracker.
Thanks a lot for reporting.
Edit: the issue is already fixed.
The question is not very clear to me, but if the problem is the fact that "the first view will be stuck with the selected styling", have you tried to add setAutoselect(false) to the tabbed menu in your MainLayout?
Here it is:
private Tabs createMenu() {
final Tabs tabs = new Tabs();
tabs.setOrientation(Tabs.Orientation.VERTICAL);
tabs.addThemeVariants(TabsVariant.LUMO_MINIMAL);
tabs.setId("tabs");
tabs.setAutoselect(false); //Needed not to select first tab by default
tabs.add(createMenuItems());
return tabs;
}
I've been trying to solve this particular bug for quite a while, but I haven't made any progress in fixing it.
Anyway, the bug basically is where when clicking on an input, the keyboard will cover the input until I start inputting numbers, at which point it'll scroll down correctly.. (Also, it suddenly loses its translucency and becomes solid... I'm not sure what's causing that either...)'
I've already uninstalled ionic-plugin-keyboard, and downgrading cordova-plugin-ionic-keyboard to version 2.0.5 didn't fix the issue for me (I'm currently running v2.2.0). I'm also running the latest version of cordova-plugin-ionic-webview (v4.1.2)
Here's an imgur link showing the bug in action
Thank you!
Unstable for IOS 13
"cordova-plugin-ionic-keyboard" KeyboardResize feature is unstable for IOS 13.
Issue is still open on git with no proper solution.
View not resizing on iOS
I am using it in both Android and IOS so i had to came up with a workaround in my code(not a good one btw but works so i am putting it here).
Step 1: Set resizing to none in for config.xml
<preference name="KeyboardResize" value="false" />
Step 2: Add an empty div just above your footer with display set to none.
<div class="keyboardFix" style="display:none"></div>
Step 3: Now set the height of .keyboardFix class equal to keyboard height and make it visible just before keyboard using "keyboardWillShow" event.
window.addEventListener("keyboardWillShow", function (evt) {
if (rootParams.baseModel.cordovaDevice() && rootParams.baseModel.cordovaDevice() == 'IOS') {
$(".keyboardFix").height(evt.keyboardHeight * 0.9 );
$(".keyboardFix").css("display","block");
}
});
Step 4: Make is go away just before keyboard hides.
window.addEventListener("keyboardWillHide", function (evt) {
if (rootParams.baseModel.cordovaDevice() && rootParams.baseModel.cordovaDevice() == 'IOS'){
$(".keyboardFix").height(0);
$(".keyboardFix").css("display","none");
}
});
Note: If condition only required if you are using same UI for cross platform i.e. Android
I have been working on this app for months now and from as far back as I can remember I have never had an issue with segues. The code is unchanged in terms of calling performSegueWithIdentifier but since my recent update to Xcode 7 and iOS 9 I have not been able to tack this issue.
I have tried:
Deleting button and creating new button w/ segue link
Using a direct segue from button to view, without the use of performSegueWithIdentifier
Connecting button to new blank viewController
When I press the button, no initial load functions are called on the destination VC (Ex: ViewDidLoad, ViewWillAppear, etc). When I connect it to a blank view, the segue works fine with the same code in place.
Since the code never stops, or breaks, and just seems to "freeze" in place while still running on Xcode I can't seem to even narrow this down to whats causing the issue. I have a similar segue that is also called from another button on the same ViewController that has no issues whatsoever.
Any thoughts on the matter are greatly appreciated!
EDIT: I have narrowed the issue down to the UITextView's causing the problem. Once the Text Views were removed the page loads fine via segue. I wonder what changed between iOS 8 and iOS 9 in terms of UITextView as I will have to remove the text views and completely re add new text views.
So basically the segue was freezing because of the UITextView's I was using in the destinationViewController. The following fixed the issue:
Delete all UITextView's
Add new UITextView's
you must leave the default lorem imposed text and change this programmatically in the viewDidLoad()
This was the fix for me, and from the research I have done on the issue it seems this is a bug in iOS 9 and Xcode 7.
Cheers!
NOTE: Removing the text in the UITextView (or making it longer then ~12 characters) is sufficient to work around it, no need to delete and recreate them. This is fixed in Xcode 7.1.1 and later.
I ran into the same issue and the fixes in this post (Xcode 7 crash: [NSLocalizableString length] 30000) solved the issue for me.
The first is to enable a localisation other than the base for the storyboard (see https://stackoverflow.com/a/32688815/3718974)
The second is to turn off the base localisation (see https://stackoverflow.com/a/32719247/3718974)
I think I have the same problem: I have a UITabelView with cells created from a nib file, when a user tap a cell this method is called:
and when I have the following method prepareForSegue:: the application crashes:
if I delete the line 129 Everything is ok , the method prepareForSegue:: open the right view and the label contactName is shown with its default text.
If I modify the method as follows prepareForSegue:: get exactly what you expect, without having any type of error:
let me know if you also get the same result
Any one who is facing this issue, i solved it by turning off the "Optimize rendering for windows scale" option in Debug of simulator window. I already had tried all of the above answers but could not solve the issue.
In the method in the first viewController where you activate the segue, do you have beginIgnoringInteractionEvents anywhere? If so the screen you segue to will be frozen and will ignore interaction events like you describe. If this is the case you can fix this by adding an endIgnoringInteractionEvents method before your segue method:
UIApplication.sharedApplication().endIgnoringInteractionEvents()
self.performSegueWithIdentifier("editItemToMyGearSegue", sender: self)
I realize this is an old topic, but appears to be still relevant. I was facing the same problem in Xcode 9, iOS11. My UITextViews are embedded inside UITableViewCells. Same symptoms as described here. The tricks with default text and placeholders did nothing for me, but I solved it by turning off the scrolling indicators for the text view in the xib. They were on by default, I guess, though unused.
Edit: this is probably an important detail... the views that were hanging all had an image NSTextAttachment in the attributed string of the text view. I think the image was wider than the available table cell content. With scrolling turned off, they appear to downscale.
I'm using a GRAILS UI (1.2-SNAPSHOT) an it's implementation of the YUI menubar (YUI 2.7.0.1). I am seeing flakey mouseover behavior in IE (Firefox is ok). When I mouse over the menu item with a submenu, it will show. As I try to mouse over the sub-menu, the submenu disappears before I can click. This happends in a pattern I haven't fully figured out. Usually the first time I select a menu it's fine but if I move around the menu back to a menu item, the submenu begins to display this behavior. By clicking and holding the mouse button I can usually get the sub-menu to stick around.
I've palyed with various configurations like keepopen and automenudisplay but they don't seem to change the behavior. I have not seen much posted about this. But I also don't see menu's documented in the UI plugin either. I could really use some feedback if UI menu is not ready for primetime yet or I'm missing something else. I've not worked with much AJAX before.
Below is the code with the added options I played with that did not have a positive impact.
<gui:menubar id='menubar' renderTo='mainmenu' autosubmenudisplay="false" shadow="true" keepopen="true">
<gui:menuitem url="/esmzone">Home</gui:menuitem>
<gui:submenu label='Profile'>
<gui:menuitem url="${createLink(controller:'memberProfile', action:'view')}">View</gui:menuitem>
<gui:menuitem url="${createLink(controller:'memberProfile', action:'profile')}">Edit</gui:menuitem>
<gui:menuitem url="${createLink(controller:'user', action:'account')}">Settings</gui:menuitem>
<gui:menuitem url="#">Subscription</gui:menuitem>
</gui:submenu>
Here is the code generated by the plugin:
<script>
YAHOO.util.Event.onDOMReady(function() {
GRAILSUI.menubar = new YAHOO.widget.MenuBar("menubar_div", {'autosubmenudisplay': false,
'shadow': true,
'keepopen': true});
GRAILSUI.menubar.render('mainmenu');
});
</script>
I made some progress on this by researching the YUI library. There is a documented bug with IE7. Apparently the grails-ui plugin does not address the fix. I'm testing with IE8 but I assume it's still there.
http://developer.yahoo.com/yui/menu/#knownissues
It appears that you should set the zoom property to 1 (zoom:1) for the bd class.
I added the following code to my style sheet
div.yuimenubar .bd {
zoom: 1;
}
and it seems to help. I see no side effect in Firefox but I didn't dynamically check for the version of browser as I would need to hack the code that generates the YUI javascript and put in
if (YAHOO.env.ua.ie === 7) {
YAHOO.util.Dom.addClass(document.body, "ie7");
}
after the render() call. Then instead of the style I added you could do an IE7 (probably >=7) style.
This is what the Yahoo site had to say about it:
The following application of
"zoom:1" sets the "hasLayout"
property to "true" and prevents
first tier submenus of a MenuBar
from hiding when the mouse is moving
from an item in a MenuBar to a
submenu in IE 7.
For more on the "hasLayout" property:
http://msdn.microsoft.com/en-us/library/ms533776(VS.85).aspx
I have a form inside jQuery tabs; I create tabs in a simple way:
$("#tabs").tabs({selected: 1});
The selected index 1 is the tab where form is placed. The problem is, on remote computer with IE6 both selects only display a small blank line instead of list with options when dropdown arrow is clicked:
Incorrect dropdown http://queen3.at.tut.by/DropDownIE6jQuery.PNG
The options are there in page source, and everything actually works on other machines, in other browsers and also in IE6 (though I use IETester).
Everything also works if I
remove tabs creation, that is .tabs() - options do appear and work; or
first select tab without form (tab 0), and then click on it - options do appear and work
only when clicking; programmatic .tabs("select", 1) after tabs creation doesn't help
Does anyone know what can cause this? Is it IE6 bug or something with my scripts?
Update: hm, thanks to this, I found it's something with my CSS - if I disable Site.css it works. I thought about scripts only. Still have to find out what's that.
Update: OK, this was caused by this CSS rule:
body { font-size: 0.7em; }
It works if I set 0.8 or greater, but for 0.7 and less IE6 does the indicated bug.
Can someone explain this? Yes it is IE6 - weird by definition, but this one is too weird in my opinion.
I have also ran into this exact problem, although I couldn't fix it by altering any body font sizes, I did manage to get around it using the (slightly modified) "Ugly hack" method as described in the dev.jqueryui.com/ticket/4734 link, posted by CiscoIPPhone:
// Ugly hack to switch tabs in IE6, fixing select menu bug.
if($.browser.msie && $.browser.version.substr(0, 1) <= 6) {
$("#tabs").tabs({ selected: 1 });
setTimeout(function() {
$("#tabs").tabs("select", 0);
}, 10);
}
Seems as though the timeout is the key to avoiding this bug.
I found that this workaround fixed the issue on some machines, but not on others.
My solution was to hide all the select elements initally in the style sheet, then after calling $( "#tabs" ).tabs() I use $('select').show() to display them.
That fixed it for me.