The text selection behavior in a WKWebView seems wrong when compiled with macCatalyst. Normally it's possible to expand and contract a selection. In a WKWebView on macCatalyst it seems that it's impossible to contract the selection. This is happening with Xcode 11.4 (11E146) on macOS Catalina 10.15.4.
Is this just a bug? Or is there a workaround?
Behavior in macCatalyst WKWebView
Behavior in macOS Safari
The only thing the macCatalyst app does is load a WKWebView from a storyboard and then load a website using this line of code:
webView.load(URLRequest(url: URL(string: "https://developer.mozilla.org/en-US/docs/Web/CSS/cursor")!))
Any ideas?
Related
I have an issue with the fullscreen state of my QMainWindow (I use QT 5.3.1).
It works perfectly well with Windows and Debian on a PC, but when I try it on a tablet PC (C22 Tablet PC, Ekoore) with Ubuntu 14.04, the behavior is different.
As you can see on the below screenshot, the task bar and the window border are hidden, but it seams that the window is not resized to take all the screen...
http://postimg.org/image/ouyb1fvz5/
I confirmed that by printing debug in the resizeEvent method. Nothing happen when I call showFullscreen().
What is wrong here ? Have you any ideas ? I cannot find anything about that problem.
Thanks in advance. Cedric
I fixed my problem. My window was too big and a part was out of the screen before the call to showFullscreen().
It seams that the resize does not work in this case.
After resizing my window in Qt Creator, the fullscreen now works fine. I do not have a better answer about why it does not work on ubuntu when the window is too big.
i try to use the inputRichText component in internet explorer 11 but it seems that the constrolls to change the font size or font type does not work.
The problem causes when i work in document mode 9 to edge (default is 7)
Is this an known issue?
Is there a way to round it?
Thanks for helping me.
There's a bug where ckeditor doesn't work with IE11 unless you set document mode to IE10. Force IE11 to run as IE10 by using a phase listener with:
response.setHeader("X-UA-Compatible", "IE=10")
For an example phase listener see http://openntf.org/XSnippets.nsf/snippet.xsp?id=phase-listener-to-set-ie-to-edge-or-x-ua-compatible-value
Does that help?
For some crazy reason, there are these boxes that are showing up on line breaks within text on a site that I am working on within Safari version 6.0.3 (8536.28.10) (see attached screen shot)
I've tested this out on a different Mac running the same version of Safari and I cannot replicate the issue. So, I am not sure what could be causing this issue. Both Mac's are running up to date versions of Mountain Lion. So far it only seems to appearing on one particular Mac.
The font on the site is using a Google font called Source Sans Pro.
I've created an application using Primefaces. It works well on Firefox, Chrome and IE 9.
But there are many issues using the application on IE 7.0.5730.13.
I'll list some problems:
DialogBox opens after clicking twice on a Button and page refresh
DropDownBox is just a gray box, only after clicking on it the list opens, it just don't looks like a standard DropDownBox
Tree table does not look well, some nodes pass over the tree table and just hang there
It looks that Primefaces is not compatible with IE 7.0.5730.13.
I researched a lot, but couldn't find anything on that issue.
Thanks in advance.
EDIT
For all those, who still have problems with Dialog Boxes in IE Browsers
remove "modal=true"
set a fix width for your dialog box
set a fix height for your dialog box
For the most part you are correct, PrimeFaces and most any JSF component framework is not compatible with IE7. Furthermore there are a few more advanced JSF components that utilize HTML5 features and may not work correctly in IE8 as well.
On that note, IE7 is an ancient browser and it is ridiculous if your client insists on support for it. If they must use IE7 for some proprietary legacy software then you can always suggest using a proper browser for your software instead, like any supported version of Firefox, Chrome or Safari.
Primefaces is supposed to support IE 7 until version 3.5 (which is not supporting it anymore). If you are using this version just downgrade it to previous one. However, I can't be more agree with #maple_shaft.
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.