I'm currently trying to port my Chrome extension Prime Player to Opera. It has a miniplayer that is opened as a separate window (using windows.create) of type "popup", "panel" or "detached_panel" (depending on a user setting). The latter ones seem to not be supported at all (which is acceptable since they are experimental in Chrome) and type "popup" displays the address bar (which is completely useless and ugly here). See the Opera version left, the Chrome version right:
My question is: Is that a bug or is there some option to hide the address bar?
The spec just says that chrome.windows does not differ from the Chrome implementation. So, I would expect this to work the same way which means:
no address bar
"panel" / "detached_panel" fall back to "popup" if "--enable-panels" flag is not set
option under opera://flags to enable panels
I also tried to open a window of type "popup" with a mod of the sample window extension which did not work either.
Maybe the difference just has to be clarified in the docs.
Other issues are that the window icon (added by a <link rel="shortcut icon">) is not respected in Opera and that the popup has a forced minimum height which leads to empty space at the bottom.
Related
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 suppose this example should respond to mouse clicks: https://github.com/ghcjs/ghcjs-dom-hello , right ? But when I try it with GHC 7.10.1 under Firefox and Chrome nothing happens when I click on the page.
Any ideas ? I haven't tried it with GHC 7.8.4 yet. But I will.
One thing it could be is that ghcjs-dom-hello currently uses onclick on the body of the document. Not all of the window will be clickable. Try clicking on the Hello World text.
The new version of ghcjs-dom in github (currently requires the imporved-base version of ghcjs) includes document events (I left them out of the old version by mistake). I'll update ghcjs-dom-hello to use them once improved-base is merged into master and the updated ghcjs-dom is in hackage.
I am working on an application build on Dojo 1.4 and currently used on IE8.
When tried to run IE10 Compatibility view, I observer some X (to clear the data) are being show in the fields like dijit.form.Select. While in IE8 it doesn't display them
Please guide to remove them or what basically is happening
Thanks in Advance
If this is the same problem I just fixed then the question isn't referring to the IE10 "clear field" X. It's referring to a very large text "X" character that is displayed in the Select widget in addition to the options that are supposed to be there, making the widget twice as tall as it should be.
In my case it was because I was mixing the CSS stylesheet from one Dojo version with the API's from another. Check to make sure that your stylesheet and dojo.js versions match. For example, in my case the stylesheet was:
...href="//ajax.googleapis.com/ajax/libs/dojo/1.7.5/dijit/themes/claro/claro.css" media="screen">
while the script being included was
... src="//ajax.googleapis.com/ajax/libs/dojo/1.10.1/dojo/dojo.js"></script>
I blame the fact that I was modifying Dijit sample code without knowing what the heck I was doing...
Since Opera no longer implements the shortcut "/." to visit slashdot.org, I thought to write an extension that replaces that functionality.
I have not previously written an Opera extension, so I hit the docs.
Setting up an omnibox extension doesn't work, because it requires the user to put a space after the keyword.
As "/." isn't a valid URL, I'm not seeing an obvious way to intercept it.
My issue boils down to "how do I get the text before Opera assumes the user is trying to do a keyword search?"
"/." is valid url, but this is not working in Opera.
This is bug which should be fixed soon. But still you will have to wait until
user will put space and the start typing text to omnibox.
Event onInputStarted is the earliest event you can catch. I tried
chrome.omnibox.onInputStarted.addListener(function () {
chrome.tabs.create({url:"http://slashdot.org"});
})
and browser create tab after user type first letter.
I'm developing a cross-platform browser extension, and have based all my code on the Chrome-way of doing this. I have counted on that the background page will be accessible from the options page, which in Safari extensions turns out to be not possible (since there is no such thing as an options-page). You can only access safari.extension.globalPage.contentWindow from within the extension popup, and the background page itself.
Now, I have an options page, which is an html-page within the extension bundle, and so far I haven't found a way for Safari to give it extension "rights". The closest I have come is adding a content script that's only added on the options page. This seems a bit silly, since the html page itself is in the extension bundle?!
Others have suggested using asynchronous ping-pong style message event handlers, and even the canLoad-mechanism (which is "only" able to run in a beforeload-event). I have been able to hack the canLoad-mechanism for synchronous messaging by forging the BeforeLoadEvent:
// Content script (run from anywhere)
var result = safari.self.tab.canLoad(new BeforeLoadEvent, "data")
-> "return value"
// Background page
safari.application.addEventListener('message', function(e) {
if ( e.name === "canLoad" )
e.message = "return value";
}, true);
It's a hack, but it works. However, I am crippled by the message transport serialization, since I need to be able access methods and data on my objects from the background page. Is there anyway around this?
Possible ways that might work but I don't know if possible:
Access options-page window-object from backgrounds page. Is that possible?
Message passing, need to bypass message serialization
Any shared/global object that I can attach objects to and fetch from the options page?
Make Safari run the options.html page from outside the content-script sandbox? It works in Chrome since they are both within the extension-bundle. It's quite annoying that safari doesn't do this too.
Run the options-page from within the popup. This is promising, but it crashes safari (which is very promising!). However, from the looks of it it's just something to do with a CSS animation in my options.html page. The biggest issue is that it has to be able to open an OAuth2 popup, but thanks to being able to programmatically open the popover, it might be a non-issue. However, this option is the most realistic, but I would rather have it open in a new tab.
Any suggestions and hackish workarounds would really help.