In my summarytools package, users have the option to view html results in Rstudio's Viewer pane, or rather in their default browser. Here's the relevant chunk of code:
utils::browseURL(paste0("file://",htmlfile))
where the path to htmlfile is defined using tempfile().
This works fine in the default R interface, but in RStudio, the path transferred to the default browser (Chrome in my case) is, for a reason unknown to me, transformed such that for instance:
file://C:/Users/Dominic/AppData/Local/Temp/Rtmp6neOOm/file2c3032b032f3.html
becomes, in the browser's address bar:
http://localhost:12245/session/file2c307cb3e22.html
... causing the browser to display a "This site can’t be reached" error page.
One solution, on Windows, is to use shell.exec(htmlfile), but this would not work on Linux unless I'm mistaken.
Any ideas as how to prevent RStudio from doing this, or on an alternative solution other than shell.exec()?
Related
UPDATE: At time of asking this question, this was related to SignalR library and not plain WebSockets. I see correctly formatted messages now.
Is there any way to word-wrap messages in WS tab in Chrome Developer Tools or display JSON with formatting ? It's really annoying to scroll to right to see whole message.
Example with message selected and it's preview doesn't have any formatting or word wrapping applied:
Thank you in advance.
It's working fine here on Chrome/78.0.3904.97:
What I did:
Go to http://crawl.develz.org/play.htm
Open one of the listed servers
Start devtools
Go to the Application tab and add a cookie called "no-compression" with value "yeah no" to the relevant server. (Any truthy string should work, I just chose the least confusing one I could think of in about a minute.)
Otherwise, crawl's webtiles server can end up compressing messages even when browser supports RFC 7692's "permessage-deflate" extension, which ruins the demonstration.
Open the Network tab
Reload the page
Select the "socket" request, switch to the "Messages" tab, and pick a frame.
Start drilling down in the tree view in the bottom pane!
I noticed strange behaviour on TYPO3 tx_news list view. Sometimes on the bottom of the page appears unknown characters. I don't know how and why and it's only on one (list view) page and in chrome browser. Here is the screen shot of that:
I have noticed that I can call out that behaviour when I change some tx_news configuration in Extension Manager eg. "List actions shown in Flexforms"
Any suggestion what is wrong?
[EDIT:] After turn off OpCache - problem doesn't occur. Could it be related?
You best bet is to install XDebug and call your page with ?XDEBUG_TRACE=1
You can then search for the offending pattern in your trace file and find the very first place where this offending pattern occurs (if it's not random of course). This gives you the very best chance to figure out why it appeared at all.
I'm trying to make a bookmarklet that will set an SVG filter over the entire page it is loaded into. To that end, it sets a style on the root element:
document.children[0].style.filter='url(data:image/svg+xml;base64,PHN2ZyB4…#h)';
This works well in Firefox, but Chrome seems to think that it is unsafe cross-site content, drops the filter, and outputs a warning to the console:
(source: codl.fr)
Is this expected behaviour? I would like to be sure before I file a bug. If so, how else can I acheve this?
Here is a test page containing the bookmarklet: http://f.codl.fr/1402/hacker/
I have a page in XPages that I use to open and edit a document. There are two ways to open a document in edit-mode: first in read-mode then click a button to put it in edit-mode, or open it directly in edit-mode. Both work in all browsers, yet IE seems to handle both cases differently. We found this out when working with the SWING API.
Opening directly in edit-mode in IE (8/9/10) works, via read-mode to edit-mode doesn't. What we found is that the internal representation of a textarea field differs: when opened in edit-mode, there are more properties, but most importantly, the return+linefeeds are correctly set in both the value and the innerText property.
The button just contains a simple Change Mode action.
Has anyone heard of this anomaly? And does someone know what we did wrong?
PS I'll try to build a simple XPage that shows this behaviour more clearly tomorrow.
For IE switching from read to edit mode, you need a full page refresh
Hey. the busted website is: www.mgxvideo.com/mgxcopy-alpha-3, and the specific error that I'm getting is the thing where IE prints out all my source code.
As far as I can tell, the error is appearing at random in IE6, 7, and 8, but it's a commonly occuring error. I'm looking for explanations, debugging tools, fixes. Anything is appreciated, because I'm fully stuck.
Here's how to reproduce:
Add item(s) into cart.
At the display cart (the url shud end with cart_display_ie.php)
Use the shipping calculator over and over and over again until you get the error. It's happened one the first, second, 5th, and the 17th try.
Reset cookies to restart from fresh
Here are some possibly relevant details
1and1 hosting, php from scratch, and mysql
I'm using Mark Sanborn's php code to interface with UPS's servers.
I'm using a local DTD for xhtml transitional 1.0
This error also appears in the checkout cart and also seems associated with the UPS function.
This isn't directly relevant, but IE also plagues me with "The XML page cannot be displayed."
Occassionally, the "The XML page cannot be displayed" is displayed as a small canvas within the context of a source print like the error I'm printing. It'll appear near the location of the error in html source, except the canvas has a really small width and height, and not display any further source code afterwards. I've fixed all these errors; they were all caused by improper syntax or w3 rationing of DTD downloads.
The cart_display*.php is responsible for adding products, removing products, and calculating shipping.
Sometimes it's something stupid like custom settings on my computer b/c I tweak with random settings that cause side effects. But I've tested in msft's VirtualPC, and had friends reproduce the error.
Here are some resources of similar problems. I haven't tried them because--even if they work--they mean that the website doesn't work at typical/default settings.
http://www.techsupportforum.com/microsoft-support/internet-explorer-forum/168285-ie7-problem-printing-html-xml-source-rendering.html
http://www.computing.net/answers/windows-xp/ie6-printing-problem/160128.html
Like I said: any explanations, tools, guesses, or fixes are fully appreciated. I'm trying to finalize the site so I can present it as a beta within the week, and I'm fully stuck. Also, is there a workaround (like a tag) that can hide this error from the user?
I grabbed a network capture of the repro using Fiddler (www.fiddler2.com).
It looks like you're sending an HTML comment containing a webservice result before the HTML body. It further looks like IE is subsequently sniffing this as an XML body instead of a HTML response.
It appears that if you move your HTML comment inside your HTML tag, the problem goes away.
Note that you should confirm changes in a new browser tab. Once IE is on an XML page, simply hitting F5/Refresh isn't necessarily going to show you the HTML content properly due to caching of the MIME-type decision.
To resolve this issue, you need to re-register two dlls.
Open a elevated command prompt and type following commands
regsvr32 /i mshtml.dll
regsvr32 /i shdocvw.dll
For detailed fix steps, visit http://geekzsupport.com/internet-explorer-prints-html-source-code/