Chrome Version 108.0.5359.124
OS: Ubuntu 22.04.1 LTS (Identified the same on Windows 10 too)
Ember.js (ember-cli 3.3.0)
When clicked on a small element (clear input button), with touch enabled on Chrome Developer Tools mobile simulator, it triggers the adjacent element (which in this case is a text input box) instead of the one it was intended to, or doesn't do anything at all if the padding of the intended element is too small. If the space is large enough (>10px) between the input box and the clear button, it works when clicked with around 10px offset away from the adjacent input element (the input doesn't have a margin or padding at the moment). This is where I'm confused about whether it is a Chrome bug or something else is going on.
On Desktop mode, it works fine with or without touch-enabled. With mobile (no touch), it works fine as well.
Tested on Firefox 105.0.1, it works fine even with mobile (with touch).
I have seen many older posts in this regard citing bugs with Chrome, but couldn't find anything regarding newer versions.
This is what I'm working with, (ember.js with ember-cli 3.3.0)
<div class="layout-container full-width">
<div class="layout-col"><i class="icon-search"></i></div>
<div class="layout-col-24">
{{input id="helpSearch" class="full-width" type="text" placeholder="Search" value=searchKey}}
</div>
<div class="layout-col" {{action 'clearSearchText'}}><i class="icon-close-circled"></i></div>
</div>
actions: {
clearSearchText: function () {
this.set('searchKey', '');
}
}
Any workarounds to fix this?
Related
I recently updated the GTK3 lib I am using, both on windows and linux,
from version 3.20 to 3.22, and I noticed some bugs in my application (GTK3 + OpenGL using the GtkGLArea widget) appearing after the update.
The bug, namely the disappearance of window decoration appears after a precise, yet simple, succession of events:
1) screen shot before the bug:
2) Exporting an image from this window (using a framebuffer for off-screen rendering)
3) After saving, going back to the main window by closing the dialog box, note that the upper menu bar now appears like if de-activated (grey) but sill works:
4) ... and when re-sizing / hiding / showing again 'ie. configuring' the window the decoration disappear:
5) The menu bar still seems to be there and works fine:
Obviously I looked carefully to the code after the saving action, but what happens remain elusive to me and I do not know what to look for.
The program does not stop and keeps working fine.
There was absolutely no problem with GTK3 3.20, and the bug appears both on windows and Linux.
What can I do to correct this situation ?
In the Gtk-3 series there have been many changes to the CSS system. If you are not using the default Adwaita theme, then probably you have to search for an updated version of the theme you do have installed. It might even be possible that the Adwaita theme wasn't update correctly during your upgrade.
Anyway, nearly all appearance problems are due to changes in the CSS system - Gtk doesn't really occupy itself with the aesthetics anymore.
I have a mixed mode win form app that does numerical analysis and then creates a report using COM automation on MS Word.
The app has a status window that shows the progress of the analysis. After the COM automation finishes creating the word DOCX report the app's appearance changes when running on Windows 8.1. There is no change on Windows 7.
The situation occurs if the winform app is x86 or x64.
The version of MS Word is 2007 x86 version.
Here's the original look of the form:
http://codeinsight.com/Pub/G31_Win8_Before.jpg
After running the app and the report is created it looks like this:
http://codeinsight.com/Pub/G31_Win8_After.jpg
The window shrinks and some fonts shrink too.
Can anyone give me a clue as to what is happening? And why it happens on Win81 and not on Win7?
Right-click on Word shortcut on the desktop (or on programmes), Select "Properties" and display "Compatibility" tab.
There is a checkBox "execute with a 640x480 resolution".
If it is checked, uncheck it.
If other options are checked, uncheck all.
Using the hint from Graffito's answer I was able to resolve the issue. I checked the "Disable display scaling on high DPI settings".
I have an IE Browser Helper Object (BHO) (written in C++) which records the height and width of iFrame(s) and the Main page when it receives a document complete notification (OnDocumentComplete). This code has been running fine up until now (all older Windows and IE versions) but has stopped working in IE11 (desktop) on Windows 8.1 for iFrames. Getting the width and height for the Main page still works.
I am using the get_Height and get_Width functions from the IWebBrowser2 interface. A call to these functions now return an error, 0x80004005 (Unspecified error) and the height and width returned back is 0.
Has anyone encountered this issue? It sounds like this could be a bug in IE11. Any help will be appreciated.
Thanks!
I've observed that IE9+ (including IE11) seems to fire onload= type DOM events "early," before the entire DOM is loaded. In particular in my case where I've got the browser DOM loading an SVG document. Webpages having <object> tags in them might be another risky area. My work around was to catch the onload= event, then wait another 0.75 seconds for the DOM to settle down. An imperfect, crazy hack, but it seemed to help.
I'm having a weird occurance with my app in iOS 7 (using the GM build).
I have four tabs, and I have a customized tab bar, with background, icons, etc. I have my code below for setting up tab bar properly:
[[UITabBar appearance] setBackgroundImage:[UIImage imageNamed:#"tab_bar.png"]];
[[UITabBar appearance] setSelectionIndicatorImage:[UIImage imageNamed:#"tab_selected.png"]];
[[UITabBarItem appearance] setTitleTextAttributes:#{UITextAttributeTextColor: [UIColor whiteColor]} forState:UIControlStateHighlighted];
[[UITabBarItem appearance] setTitleTextAttributes:#{UITextAttributeTextColor: [UIColor whiteColor]} forState:UIControlStateNormal];
I have four tabs, and when the user selects any of the last three tabs, everything works fine. But when the user tries to go back to the first tab, the tab switches, but the selection doesn't switch. It still shows previous tab was selected. If they tap again, then it switches. Is there any other change for iOS 7 I should be aware of? It appears iOS 7 is losing track of touches here and there and I was not able to find anything else.
I got that too and am pretty sure it's a bug in ios 7
I have having a bit of a problem that may be an issue with my code or it might be an issue with the client not realizing something he needs to do. I am developing a Silverlight5 app that prints and is used by both Windows machines and Mac Machines. The problem is that our printouts will not be on the standard letter (8.5" x 11") paper size. On Windows I get a print dialog that let's me set up the size and orientation (Landscape/Portrait) of the document I have loaded. The client gets a dialog, but that dialog does not let him specify landscape orientation (it's a different dialog than his normal Safari dialog).
So the question is there something I need to do in my code to enable Landscape printing on a Mac OR is my client missing something in the Mac print dialog for Silverlight?
Ok, here's the specific answer that I have turned up.
Direct Landscape printing is not possible. You have to turn your printed visual manually (well, with code).
I wrote a blog post on this here -- http://www.jaykimble.net/forced-landscape-printing-in-silverlight-on-a-mac.aspx