I have a site using self hosted TinyMCE on a page hosted in AWS. It works fine for 95% of people but one customer has a desktop image that has issues. The TinyMCE Rich Text Editor shows but the input box does not allow any input (Firefox, Chrome, and Edge all have the same problem on this image). The SAME customer in the same building has a 2nd desktop image and on that machine the editor works fine.
I'm pretty confident that the issue is with the network or the desktop policy blocking something.
I need help determining how to troubleshoot finding what exactly that might be. So I can ask the client to make changes to the desktop or network policy. The challenge is that this is a large organization and that change will be riddled with red tape. So I need to be really sure that the proposed change will be the right fix.
What can I try? What should I look for?
Related
I am having some recent problems with TFS 2018 that have escaped my ability to troubleshoot. The application runs on a Hyper-V VM hosting Server 2019 and connects to a separate MS SQL 2016 database over on a separate Windows 2019 VM.
A few weeks ago we migrated our database server over to a new machine which, over the course of setting our existing TFS server up to use the new database, required us to run though the TFS setup wizard again.
Everything was fine for about a week when we started to have issues, specifically with the TFS web front-end we use. First we lost various icons on the webpage, with the browsers (Chrome, Firefox, etc). replacing them with rectangles:
A little while after that we lost our project Dashboards, and the whole dashboard page is just blank now. A little while after that, our WIP build/test automation feature also lost its management section of the site.
Other than these things not displaying, things generally "work" - the source control stuff functions, work items can be interacted with, etc. It's just that the interface is clumsier without the icons (which extends to every icon within every work item type, not just the banner I shared) and we can't get our automated test reports without the site's front-end for it. The latter is the real show stopper.
I spent some time troubleshooting and at best was able to figure out a maybe solution for the icon problem: https://social.msdn.microsoft.com/Forums/en-US/c1038468-9d94-473d-a020-254789e9a19b/tfs-2015-update-2-missing-icons?forum=tfsgeneral
This seemed to do the trick for just the icon problem, though some time later they disappeared and reappeared when people were refreshing pages. I'm still unsure if the re-failure was a fluke or not, as we rolled back the VM snapshot the changes were made on shortly after.
Using Chrome's developer tools, it seems like the lack of dashboard data is related to issues retrieving content on the host server for a cause we cannot determine.
Here is what shows up on the DevTool in Chrome for our main project's Dashboard:
What's interesting is the error claims widget.css is either not present or empty. Neither of these are the case as I can find the file and read data in it.
I recognize MIME types as a thing that shows up in IIS but I don't know what to do with the information. Should I be adding .css to the MIME Types list within IIS? Maybe that was set and the wizard reverted it?
Here's what shows up in the Builds section:
Thing is, I don't know what to do with this information. I found some vague hints online from people having similar issues with sites they were themselves coding (which stated the errors in question were red herrings), but this TFS front end is not something I've created and I had not any idea what to do with the information shared.
Does anyone have an idea of what might have gone wrong with the dashboards here? I have run out of ideas and can't figure out a different attack angle to approach this from.
We recently upgraded to the latest version of Tableau and are encountering a serious problem. No-one in the tableau community has answered the question and even our paid Tableau support is not responding to us!
We are embedding a viz in our site and then allowing users to click on the "Edit" button which opens up a web-edit version of the workbook. We have special permissions setup that allows them to even save their changes. This has all been working fine.
As of the most recent upgrades where Tableau introduced this idea of a Personal Space we now get a 401 when trying to save in the Web Edit (now labelled "Publish as")
Clicking "Publish As" loads a modal which is meant to display a list of locations to save to but instead displays a spinner which never goes away. The console indicates an error specifically wit the new personal space - 401 - No authentication credentials were provided.
We are using trusted ticket authentication to display our embedded vizzes and have had no problems with web edit saving until now. If we log directly into Tableau the web edit saves perfectly. So it seems to be an issue of Web Edit Saving + Trusted authentication, specifically as it relates to personal spaces.
Seems clear to me that this is a Tableau bug but wondering if anyone can suggest any kind of fix or workaround.
Thank you
This has been confirmed by Tableau as a bug in their latest versions. Unclear when it will be fixed.
They provided us with the following workaround (which is not ideal from a security perspective) but works.
Workaround provided by Tableau. Configuration change required, setting unrestricted tickets to true.
https://kb.tableau.com/articles/issue/login-prompt-when-embedding-server
This is a temporary measure while Tableau develops a more permanent solution.
I was using IE10 on Windows 7 but it is such a buggy piece of you-know-what (hanging, crashing, etc.) that I gave up and installed IE11. It has not hung or crashed since installing. But I hate the F12 developer tools! Okay, not completely - there are some very cool new features. What I don't like is that they seem to have dropped several features that I really liked! Unless I'm just missing something... I've searched and searched on Google and Microsoft but all of the help I've found only describes the new features. Here is what I'm missing: Color picker, Ruler, and most of all, the Clear browser cache for this domain. They allege to have a Clear browser cache function, but it doesn't work! So when I make changes to my website, in particular changing graphics, the only way I can see the change is to delete all my temporary files from IE. Then I lose all of my cookies e.g. for automatically logging in to Stack Overflow! IE version 11.0.9600.16428 on Windows 7 Ultimate 64-bit.
The color picker is still available, go to the DOM Explorer tab and there is an eye dropper on the tool bar at the top towards the left. That activates the color picker.
For the issue of serving cached files try toggling on "Always refresh from server" on the network tool (3rd option from the left). This should get you the latest changes from your server.
In building a Tumblr theme I've got an external .css on my server which is very convenient because I can work directly in my editor, save to my server and refresh to see my results.
However, if I need to make changes to the HTML of my theme I've been making the changes in my editor, copying everything over to the "Customize Theme" option in Tumblr, then having to save there. This is really tedious and cumbersome because of the way their editor is laid out (the html covers the entirety of the the preview).
Does anyone have a smoother workflow?
Even if it involves just viewing my .html directly from my server when tweaking, then pasting it in when done. Like some way to inject test content so it's not just the html template tags?
While Tiny Giant Studios is right as far as the Theme Garden is concerned, there's nothing stopping you from externally hosting 'til your heart's content while you're actively developing.
To that end, you might try Tumblr Themr. I haven't actually tried it yet, but it sounds promising enough.
EDIT: Seeing as the original link is not resolving, you may also try their github page
The short answer is an unfortunate no.
The Tumblr system requires that all assets (from CSS files to images) be kept on the tumblr server. Seeing as theme developers (at the moment in any case) do not have direct ftp access to a theme's directory (if that even exists), one cannot work from an editor (e.g. notepadd++) alone...
I'm not sure if they're looking into changing this, but for the time being we're stuck with being copy/paste solutions.
One thing you could, however try is copying over all the HTML markup and then using browser plugins - like stylebot or developer tools for chrome - to write the CSS and once you're done, copying over all the CSS in the head section of your theme.
I have recently found that Tumblr features GitHub integration where you can just push to a repository and it updates the theme on your blog. I have not tried it myself but I probably will here in the next few hours.
Check it out!
EDIT: My mistake this is only for theme creators who plan on submitting their themes to the list of Tumblr themes that can be chosen by users. Someone may still find this useful so I will leave this answer.
Is this a technology I should spend much time evaluating?
http://code.google.com/chrome/chromeframe/
Chrome Frame is a plugin for Internet Explorer (IE6-IE8) that gives it, well, what all the other major browsers have.
Biggies for me are the Canvas tag and a fast JavaScript.
As I do a lot of JavaScript dataset visualization, IE6 is a perpetual thorn in my side, and I often have to write extra code for it, and I often have to slow down the frame rate of user-driven real-time visualizations. Using Google Chrome Frame will allow me to produce a much more responsive experience for IE6 users.
But I wonder if IE6 users may be in situations where their computers are under some kind of IT lockdown hell where they aren't even allowed to install a plugin (why else would they be using IE6?)
So I'd still be left with what to do with the last poor souls in IE6.
Still, IE8 lacks Canvas and the JavaScript is slow, so some of my users would see increased performance, maybe even up to Google Chrome and Safari levels.
So again, my real question: Is this a technology I should spend time evaluating?
Note: Google will be throwing up alerts to IE users to encourage them to download Google Chrome Frame for Google Wave. So maybe Google will get enough Google Chrome Frames out there on IE machines that I can just detect it and use it if it's there, and warn the user that experience may suffer without it. I hate to demand anything of my user. http://googlewavedev.blogspot.com/2009/09/google-wave-in-internet-explorer.html
Given the visualizations you're working on, I'd definitely evaluate it. The potential upside for you as a developer and for your users is significant. You do not have to force all Internet Explorer users to use Chrome Frame. You can simply include the meta tag and the users that choose to install the plugin will almost certainly have a better experience.
That said, in my evaluation of Chrome Frame I have encountered some pretty big caveats that might be showstoppers for your project:
Older versions Chrome Frame can't print (see bug list). Depending on what kind of visualizations you're doing, this might be a real deal killer.
Downloads work but appear to the user like nothing has happened (see bug list again).
Chrome Frame is basically the Google Chrome browser shoehorned into the IE browser chrome. As such, any interaction with the browser inside the frame is with Chrome, not IE. If you right click and select Inspect Element you will get the Chrome developer tools window with its Vista-like look and feel. You'll need to make a judgment call as to whether your users will be comfortable with that.
In my testing, it appears like Chrome Frame is only looking at the meta tag:
<meta http-equiv="X-UA-Compatible"
content="chrome=1">
I was unable to get Chrome Frame to activate by setting the X-UA-Compatible HTTP Header as you would with EmulateIE7 mode:
Header set X-UA-Compatible "chrome=1"
It is also worth noting that this meta tag will override EmulateIE7 mode if you have that setting configured and I believe the inverse is also true too. They are both setting X-UA-Compatible. The last tag to set this will take precedence.
One power testing tip that will help save you from having to go in and edit your pages, is that you don't have to do anything to your site to test it with Chrome Frame. Once you have the Chrome Frame plugin installed in IE, simply prepend gcf: to the any URL and it will load it in Chrome Frame (e.g. gcf:http://dshaw.com ).
Happy coding,
- #dshaw
Think you should really spend some time on it since i just tested it and it works very well !
It gives you ie6 with the chromium speed !
And google will surely have enough power to spread it a little. Also you can advice your users to install chrome frame for your application if you really need it.
If you can install flash on ie6, you'll be able to install chrome frame.
Some users that can't install google chrome, will be able to install chrome frame.
I agree with you when you say that you don't like to demand anything of your users. That's generally a good philosophy. I would recommend evaluating how much you need the Canvas and how slow JavaScript really is.
Considering that IE is still the most popular browser (well, the most widely used, anyway), if your web-application is going to be used, you have to take IE into account (as you already are). The real question to ask is, "How much is the user's experience going to suffer if they use IE 'as is'?" If it really will degrade performance, and it will hurt your user base, then, yes, I would check out Google Chrome Frame.
I think it is a good alternative to sites which are considering not maintaining support for IE6.
Recently some big sites stopped working in IE6, they could ask for chrome frame instead of showing you can't access that site in your browser.
Is something good also for improving performance for google chrome frame users.
I'd say no. It is a waste to spend time evaluating it.
Whoever can and want to install extensions to IE6/7/8 can and should install a modern browser (Firefox/Safari/Chrome). The benefit would be both better performance and better support of standards across the board, more than a plugin for IE can provide.