Varied results for window.open - javascript

I am working on a standalone XUL application and have this bit for opening a dialog window:
window.open("./help.xul","help","chrome,dialog,centerscreen,modal,resizable=no,close=no");
On Windows 7/8 this works as expected. The dialog opens modal without any of the title bar buttons, cannot be resized and is centered on the parent. However, on Linux (tested on Fedora & Ubuntu), all but the centerscreen features are ignored.
I've also tried it using
window.openDialog("./help.xul","help","chrome,centerscreen,modal,resizable=no,close=no");
with the same results.
I'm hoping a second (third, fourth, ad infinitum) set of eyes can tell me what may be going on to cause the varied result.
EDIT: Forgot to mention that I ensured the version of XULRunner was the latest on Windows and Linux (v39.0). Same results.

Related

sitefinity 10 upgrade - Chrome not allowing edit of Content blocks

I recently upgraded Sitefinity from 9 to 10. After the upgrade I am not able to edit the content of content blocks on the pages. This only happens with Chrome. Everything seems to work just fine in IE and FireFox. After clicking "Edit" on any of the Content type controls (Content block, image, video, ect) the white loading box shows and then just goes to an all white window the the x to close it out. Any of our custom widgets work fine. There are no Javascript errors showing in the console. Has anyone seen this type of behavior and how is it fixable?
** Note ** The MVC Content types do seem to work. It appears that it's just the regular Content types that do not seem to work correctly.
Have you zoomed in or out your Chrome browser?
I've seen this issue with Chrome and WebForms widget designers.
Just try to zoom in and out the browser while the widget designer is open - you should start seeing the contents of the designer.

Bootstrap select dropdown does not open menu on Windows machines - IE, Chrome and Firefox

Building atop Silvio Moreto's Bootstrap Select I have a custom dropdown with no issues in Chrome, Firefox and Safari on Mac, iOS and Android (private browsing or not).
Windows
In Windows the select renders how visually expected -- everything looks to be in place -- but clicking the select does not open the dropdown menu (which is kind of the point).
I'm really stumped and surprised that the operating system could have such an impact on this component. I also have little experience working with Windows machines and hope someone may be able to give some clues about what could be happening.
Live example
View the problem in real time here
Has anyone experienced a similar problem? How could this happen?

GWT 2.5.1 application with erroneous behavior in older versions of Chrome

EDIT:
Furthermore, I should point out that this bug does not appear to happen whenever I'm running the application in hosted/devmode. Only when I do a full compile on it and run it in tomcat does the problem appear.
I've been tasked to investigate and possibly fix an issue we're having with a listbox widget misbehaving in certain versions of Chrome. I've discovered through testing that this appears to only be happening in Chrome/Chromium 33 and 34 (the versions me and my manager are using on Linux Mint), and is working as expected in Chrome 35 and Chromium 37. I don't have an older Windows version of Chrome to test against.
All I can say about the problem in question is that clicking on a listbox in certain areas/states of the application cause a toolbar item (completely unrelated to the listbox) to become "active", and the listbox opens and closes very quickly. Analyzing the code of the webpage shows that the class of that HTML element gets changed to add a 'selected' class when I hold the mouse down on the listbox, and reverts back to un-selected when I lift the mouse. Needless to say we have no idea where to even look in the application for something like this, especially where it's only happening on Chrome versions older than 35.
I've been asked to find out what exactly might have changed in Chrome to "fix" this bug, and if I can figure out how to fix this quirk in older versions of Chrome. The Chrome 35 changelog makes reference to something called "Unprefixed Shadow DOM". A quick search for "Shadow DOM GWT" tells me that GWT 2.5.1 has an experimental component/feature called Elemental which makes use of Shadow DOM.

Chrome browser not working as expected (onclick/onsubmit error?)

Here is one strange thing. Thanks for ideas.
My Chrome browser does not interact with some web pages as expected. When opening the pages on a different device (such as Browserstack or colleages' computers), everything works fine. There must be a problem with my device, it is obviously not linked to the browser version itself.
Example 1: click on element does not show reaction
When clicking on the small gray dots below the main image here, Chrome usually performs a caroussel switch. On my device, it does not. Clicks are constantly being ignored, although the automatic caroussel switch works just as on any other device.
Screenshot: i.stack.imgur.com/KR64m.png
Example 2: click on button does not show reaction
When clicking the button "Weiter" on this page in the lower right section of the page, my Chrome does not show any reaction. Works as expected on any other device.
Screenshot: i.stack.imgur.com/g8dHN.png
My Chrome Version: 33.0.1750.146 m (plugins disabled, surfing in anonymous mode)
OS: Win 7 Pro SP1 64 Bit
Thanks for help!
UPDATE:
I found out that my Chrome shows different results to a VisualEvent-check than Browserstack.
Have a look here:
My chrome (buggy): i.stack.imgur.com/Earrs.png
Browserstack (working): i.stack.imgur.com/zRRgA.png
What can I learn from that? There are two more event handlers
There are no VisualEvent differences for the second example, however.
UPDATE 2: On a MS Virtual Machine, everything works as expected:
My comment below
Hm do you deactivted your Javascript by accident?
https://support.google.com/adsense/answer/12654?hl=de
Have u tried a different browser on the same device?
I had this problem too, but it was solved by itself the next day. Maybe you just need to do a reboot?
Concerning my device, the issue is related to the fact that my device has a touch screen which Chromium does not know how to handle in the standard configuration. Considered a bug.
nzolghadr#chromium.org
The problem is with "'ontouchstart' in window" expression which the jquery.flexslider library uses. Right now on Windows Chrome returns that as true when you have chrome://flags/#touch-events enabled/automatic. Related issues are: crbug.com/467934, crbug.com/555746, and crbug.com/392584 which based on those it seems that Windows thinks something is touch enabled and Chrome just reflects that.
https://bugs.chromium.org/p/chromium/issues/detail?id=373991#c13

IE8 javascript debugger is now broken

I am on Windows 7, using IE8 and Visual Studio 2005. I have been enjoying the built in javascript debugger in IE8 for several months. About 2 weeks ago, I installed some security update for IE 8 (possibly KB978207) and all of a sudden the javascript debugger is now broken.
If I get a warning from IE 8 that an error occurred and asking if I want to debug using the built in debugger, if I hit yes, I get a grey popup in the top left corner (which I've never seen before) saying "JScript Debugger. Breaking on JScript runtime error - Object doesn't support this property or method". Then nothing happens. IE freezes up and then I get a Windows popup saying that IE 8 is no longer responding and asking if I want to end this process. If I try to end the process, nothing happens and I continue to get the grey popup. I usually have to kill debugging process from VS 2005, but the frozen IE8 still is present. It's not until later when the OS, finally cleans up the process that it will go away...
Edit (new info):
I tried removing the lastest security update and a silverlight update that came around the same time, but Windows automatically reinstalled them....
I then tried removing IE 8, and then adding it back to my system to reset anything related to IE8. This did not have any effect.
After reinstalling IE8, I did notice that, when I first tried to open the developer tools window by hitting F12 from a regular IE 8 window, I never saw anything, but I could see the developer tools title in the task manager list. I had to right click on the task and maximize the window, so I could actually see the developer tools window. Apparently this is a bug mentioned here: http://social.msdn.microsoft.com/Forums/en-US/iewebdevelopment/thread/79b8ee54-c5f6-4467-ba6d-27491c95cd13
I've realized that the window will maximize if the iexplorer.exe process is not the debugged process launched from VS2005.
The grey popup I mentioned in my original post is from the developer tools window iexplorer.exe process.
If I launch my app from VS2005 and then hit F12, I see that the developer tools window is opened (I can see that window is opened under the IE icon in my taskbar), but it is not shown. If I try to maximize it from the task manager, this has no effect.
So basically, the developer tools window is freezing up when it tries to open under my debugged iexplorer.exe process launched from VS2005. The OS then asks if I want to kill the process since it's not responding, but it is unable to kill it. At some later point, the zombie iexplorer.exe process is killed succesfully (by the OS I presume).
Had the same thing happening. You clued me in on the solution by pointing out F12 starts Developer Tools in the taskbar but doesn't show up on the screen. Apparently the window is off screen in nowhere land and causes major screwups if you attempt to debug in this state. So my solution was to:
Close all IE instances
Start up IE
Start up Developer Tools (F12)
Hover cursor over the the IE button on the taskbar until context menu shows
Right-click the Developer Tools item in the context menu (not the taskbar button)
Click "Move"
Start tapping arrows until you see the window come back in view. Mine was off stage left so I had to hold down the right arrow.
The window will have been sized down to just a window title bar, so resize by dragging the right corner down and out.
Once the window is moved back and resized, close it to "set" the position. You should be good to go now.
May be the security patch has disabled script debugging in IE. It was a common problem when using the debugger of VS 200X
Now on try to enjoy FireFox with the FireBug Addon. It's really great to debug Javascript. :)

Categories

Resources