I have an OpenGL application with a QWidget-based (no QtQuick/QML) Qt UI that I ported from Qt5 to Qt6. Most of it works fine, except that with Qt 6.4 and the Qt 6.5 beta (Qt up to 6.3 works fine!), the QSurfaceFormat color space setting no longer has an effect. I could not find any changes in the change log that should affect this. The only OpenGL-related change mentioned is to the RHI which shouldn't matter since I don't use QtQuick/QML.
In my main, before creating the QApplication instance I set up my default surface format and the Qt::AA_UseDesktopOpenGL attribute as follows:
auto surfaceFormat = QSurfaceFormat::defaultFormat();
surfaceFormat.setVersion(3, 3);
surfaceFormat.setProfile(QSurfaceFormat::CoreProfile);
surfaceFormat.setOption(QSurfaceFormat::DebugContext);
surfaceFormat.setColorSpace(QColorSpace::NamedColorSpace::SRgb);
surfaceFormat.setSamples(4);
QSurfaceFormat::setDefaultFormat(surfaceFormat);
QApplication::setAttribute(Qt::AA_UseDesktopOpenGL);
QApplication app(argc, argv);
In the constructor of my QOpenGLWidget-derived widget, I set a compatible texture format and the update mode:
setTextureFormat(GL_SRGB8_ALPHA8);
setUpdateBehavior(QOpenGLWidget::NoPartialUpdate);
In initializeGL I set up a QOpenGLDebugLogger and load my OpenGL functions using glad Using QOpenGLFunctions is not an option as that would imply making the rendering code Qt-dependent and/or require significant changes. I also tried outputting the name of the color space reported by the widget's surface format via qDebug() and it is "SRgb" as expected.
At the beginning of paintGL I ensure GL_FRAMEBUFFER_SRGB is enabled before drawing using glEnable(GL_FRAMEBUFFER_SRGB).
In summary, it works in Qt 5.13 to Qt 6.3.2, but stops working with Qt 6.4 (the 6.5 beta adds another bug where menus have a black background but it's a beta). I am not getting any relevant OpenGL debugger messages, just a lone performance warning due to a re-compiled shader. Am I doing something wrong that just happens to work on previous versions or is this a bug that none of the many Qt users have discovered over the course of more than one minor revision? Any ideas regarding resolutions / workarounds?
I upgraded from Testcafe 1.6.0 to 2.0.1.
I noticed there are differences in how TestCafe takes screenshots.
This is a screenshot from 1.6.0:
This is a screenshot taken with 2.0.1:
This is how it actually looks:
As you can see in 1.6.0 and in the original the "Q" looks more like an "O" because it is cropped - like other letters. overflow: hidden is set on the element.
It makes sense. This is the actual box of the screenshottet element:
The actual text is in a div element inside the screenshottet element:
It seems like in 2.0.1 it disables overflow: hidden on the screenshottet element to take the screenshot.
Is there a way to re-enable the old behaviour?
TestCafe published a new version - 2.1.0-rc.1 with a fix for the issue with screenshosts. Please update testcafe and check the issue again. If it doesn't help, create a simple sample with the following template: https://github.com/DevExpress/testcafe/issues/new?assignees=&labels=TYPE%3A+bug&template=bug_report.yaml
Description:
The scrollIntoview dusk method is not working as expected.
Can anyone please point me the right version of laravel/dusk, chrome driver version to be used to make it work again.
Currently I am using theses versions while running the script.
Laravel framework version: 6.2
laravel/dusk: 6.11
php:7.2
Chrome driver: 88.0.4324.96.
Thank you in advance.
There is a wide range of unexpected behaviours in scrollIntoView(), and related reasons...
Among the many: my own experience was about the Bootstrap navbar placed above the scrolled element, resulting in many "Other element would receive the click" errors. I fixed it with my own Browser Macro, scrolling the element at the bottom of the page (instead of top):
\Laravel\Dusk\Browser::macro('scrollView', function ($selector) {
$selector = addslashes($this->resolver->format($selector));
$this->driver->executeScript("document.querySelector(\"$selector\").scrollIntoView({block: 'end'});");
$this->pause(500);
return $this;
});
Apologies for the slightly vague question but I'm pulling my hair out. Since this update we have had numerous calls regarding printing from our web app. Our web app uses an iframe and we use css #media print to hide all but this iframe for printing purposes. Since the update the user receives an Error 404--Not Found instead of the actual page. It would seem from the network trace that IE creates a temp .htm file in the local directory like D3CD911.htm, it then downloads css/js resources and then finally it makes this call /D3CD911.htm. This is making a call to www.mywebsite.co.uk/D3CD911.htm. This obviously does not exist on the website so the 404 is returned.
I struggling to find a pattern to the problem and it doesn't seem to be affecting other public sites. I think the issue is with window.print() method. I can semi reproduce it here at https://www.primefaces.org/showcase/ui/misc/printer.xhtml. If you click the print button you will get the error. Although this is using the jqprint javascript function if you then use the browser print button it also fails.
Any guidance would be much appreciated.
andyfinch, you're a genius! The following code appears to work for a print button contained within a frame:
function Print() {
if (document.queryCommandSupported('print')) {
document.execCommand('print', false, null);
}
else {
window.parent.<framename>.focus();
window.print();
}
}
Update:
Microsoft have now released a patch: Microsoft IE patch
Just wanted to summarise the workarounds I've found and which have been posted here.
1) If you are using your own print button change to use document.execCommand('print', false, null);. Test support using document.queryCommandSupported('print') and call window.print() if not supported (Prob just Firefox)
2) Use Print Preview. Additionally select the part of the page to print, right click and select print preview. Then select As selected on screen.
3) Use another browser like Chrome
4) Uninstall the update
5) Wait for Microsoft fix. Their KB page KB Link has been updated with this as a known issue. Therefore you assume a fix is on the way.
andyfinch's workaround is also working for us. Thanks Andy!
MS has flagged this issue with "WON'T FIX" (6/15/17): https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12349663/ Update: that flag might just indicate that it's not an issue with MS Edge so it won't get fixed by the Edge developers.
Installing KB4021558 breaks printing from our website (the pages are blank, the footer shows some variant of "res://ieframe.dll/i273gyew.htm"). Uninstalling it restores printing functionality.
KB4021558 is also included in KB4022719, KB4022725 and KB4022727.
I found a workaround: if the iframe you're trying to print is visible, right click on it and choose Print preview... instead of Print... from the context menu. The preview seems to be printable (but may show only part of the frame contents).
Also, for the record, the problematic 64-bit Win7 update is KB4022719.
MS released updates yesterday (June 27th) that address it for Windows 10:
This non-security update includes quality improvements. No new
operating system features are being introduced in this update. Key
changes include:
• Addressed an issue introduced by KB4022715 where Internet Explorer
and Microsoft Edge printing from a frame may result in 404 not found
or blank page printed.
Links:
Windows 10 (Initial Release - Build 10240)
KB4032695 - Build 10240.17446
Windows 10 Version 1511 (Initial Release - Build 10586)
KB4032693- Build 10586.965
Windows 10 Version 1607 (Initial Release - Build 14393)
KB4022723 - Build 14393.1378
Windows 10 Version 1703 (Initial Release - Build 15063)
KB4022716 - Build 15063.447
Source/More info
I grabbed them from the Windows Update Catalog today, to use with WSUS.
Heres the workaround I have been using for this in IE 11:
Right click frame and choose select all, or [ctrl + A] in the frame
Right click and choose print preview
There should be an option in your preview for "As selected on screen". Choosing this allowed me to print everything in the frame.
We were having multiple frames in the print screen and calling document.execCommand('print', false, null); could not fix our issue. Instead window.parent[frameName].document.execCommand('print', false, null); fixed it.
I am working on writing a story for a bdd framework which uses jbehave/selenium/webdriver and am having a problem where the test encounters an error while running the story but appears to be fine when running manually. I'm having a problem where javascript for the functionality I'm testing behaves slightly different when I'm running tests manually on firefox vs through selenium web driver on the same system/version of firefox and this difference is causing a js error.
I've debugged and basically the root of the problem appears to be that var request_XML_container = $('div_appendpoint_id'); returns something different when I'm running the test manually vs when I run through the bdd framework.
var request_XML_container = $('div_appendpoint_id');
request_XML_container.innerHTML = encoded_xml_from_request;
var pos = method_to_get_position('id_of_place_div_should_be_appended_to');
// JS exception is thrown saying that style is not defined **ONLY**
// when running through web driver. Running test manually on
// same system and same browser works fine.
request_XML_container.style.left = (pos[0] - 300) + 'px';
request_XML_container.style.top = (pos[1] + 25) + 'px';
request_XML_container.style.display = "block";
Why this would work fine when running manually that var request_XML_container = $('div_appendpoint_id'); would return an item with style defined, but when running through webdriver that the style attribute of the element would not be defined?
UPDATE: I had originally thought that this was updating an iframe, but I read the markup wrong and the iframe I saw is a sibling - not a parent - of the element where the response is being appended to. I'm trying to simply append the response to a div. To be honest, this only makes things more confusing as grabbing a div by id should be pretty straight forward and I'm now sure why webdriver would be producing a different return element in this situation.
UPDATE 2: Steps to reproduce and information about the system I'm on:
Use webdriver to navigate to this url: http://fiddle.jshell.net/C3VB5/11/show/
Have webdriver click the button. It should not work
Run your test again, but pause put a breakpoint at your code to click the driver
Click the button on the browser that webdriver opened. It should not work
Refresh the browser page on the browser that webdriver opened. Now, it should work.
System details:
OS : OS X 10.8.5 (12F37)
IDE : Eclipse Kepler: Build id: 20130614-0229
Browser (used manually and by webdriver) : Firefox 23.0.1
Selenium version: 2.35.0
UPDATE 3: I have provided this maven project on github to aid in reproducing: https://github.com/dkwestbr/WebdriverBug/tree/master/Webdriver
Synopsis/tl:dr; Basically, in certain situations it appears as though webdriver is overwriting the '$()' javascript method with a method that does not return an HTMLElement with innerHTML or style defined (among other things). This post details the issue and how to reproduce.
I have opened this ticket to track the issue: https://code.google.com/p/selenium/issues/detail?id=6287&thanks=6287&ts=1379519170
I have confirmed that this is a bug with the Thucydides framework (understandable since they still aren't at a 1.0 release).
Issue can be tracked here: https://java.net/jira/browse/THUCYDIDES-203