I'm having an unexpected "annoying" popup in IE7 (and possibly other versions). As expected IE prompts you about unsaved form data when closing the window which is fine. But I have a form inside a div and now when I toggle the display CSS style between none and block, IE thinks I'm closing the form with unsaved data and shows the warning about closing an unsaved form! I don't want my users to be annoyed when simply hiding a form in my IE-based web app.
Anyone know how to overcome this?
Make sure that your doc type is transitional rather than strict
The prompt isn't IE's-- your HTML has an onbeforeunload handler which triggers the warning.
Related
I saw similar problems to my problem, but I have not seen useful solutions for my issue.
Situation:
When I play a video file within firefox, I can see current state of html-markup (F12) because of that I can trigger some funtions in my php behat/mink code.
The same situation occurs in IE, and I dont see current state of my markup-code and I can´t trigger my test-functions.
Example:
Firefox opens modal dialog and it appears by markup (F12) css class "open window"
IE opens modal dialog and it not appears by markup (F12) css clas "open window"
How can I detect current markup state in IE, when I can look only at markup?
UPDATE
Here is my code. I just looking for one css-selector, but it does not working
on IE10
$node = $this->getSession()->getPage()->find('css', $css_selector);
Problem beginns by IE10:
When i press F12 within IE10, i will see developertools.
I see within "HTML-section" current state of html-markup.
I click on icon and modal dialog appears.
Actually my html-markup changes after that. Some css classes come additionaly to video-tag.
I have to click by developertools on "refresh"-Button or F5 to see
currently markup-state, which contains modal-dialog.
To achieve same effekt whithin behat, i use:
$this->getSession()->reload();
That does not work. Behat can not find new css classes, which referes on modal-dialog.
Please look on picture:
I hope, it is clear now, what i mean :)
As i understood, for IE the class that you are using in the validation is not added and you are not able to check that the modal is opened.
As an alternative you could use alternative methods to verify that the modal is opened and to avoid cross-browser issues like this.
I think is better to work with what you already have without reloading or doing any actions that could lead to extra code that could affect other browser or could affect the stability of the scenario.
One way of doing this is to check that the modal is visible using isVisible() method.
I need to show a dialog box that's is like chrome's. But I want a modal alert, because js alert freeze the page.
I tried getting the css from it, but I think it's not possible.
Does anyone know how to do it? Or have the css for it?
Chrome JS Alert
You might want to check out this page. Sounds exactly like what you're trying to do. It uses the onload javascript attribute, which says "run when the document is finished loading".
http://www.htmlcodetutorial.com/linking/linking_famsupp_88.html
I have noticed a difference in behaviour between chrome and IE of handling file input clicks.
jsFiddle example here.
In Chrome, clicking anywhere on the input (text or button bit) triggers the file dialogue.
In IE (testing on 7), you have to click on the actual button, not the text bit.
The problem is that I'm using a transparent file input on top of a regular text box. Clicking on the text box should open the dialog. In Chrome this is working fine, as the total size of the input is the same size as my text box.
In IE it doesn't work properly as the user needs to be clicking on the actual button part of the transparent file input.
Any ideas of how to fix this??
Thanks
Have a look at how these guys have done it: http://www.filamentgroup.com/lab/jquery_custom_file_input_book_designing_with_progressive_enhancement/
The strategy is the the same, overlay a custom designed file input over a standard one and get the user to interact with the standard one.
They have written a small hack to support the click for IE and Opera, using jQuery to bind a click event explicitly.
See: http://dwpe.googlecode.com/svn/trunk/fileinput/js/jQuery.fileinput.js (Line 52)
You need to find a way to trigger a click event on the file input box..
Maybe adding a click handler on the underlying textbox which issues the click event to the file box.
example: http://jsfiddle.net/MqbrV/
It does not work in Firefox (but the default action should be enough) and Opera (where none works).
I've run into a strange problem with an HTML form. I've built a dynamic table that adds a new row when you enter data into an existing blank row; because there are some server requirements in adding a row, I make an AJAX call to do this in the onblur event. It took a while to make this work for all browsers, but eventually all was happy with the world ... until IE8. Now, what happens is that, when the call returns from AJAX, the cursor shows in the next textbox (correctly), but the keyboard no longer works. I have to close the modal window (actually an IFRAME), then the keyboard starts to work again. If I put IE8 into compatibility mode, it works fine.
Has anybody seen behavior like this, or have any ideas for a workaround?
Thanks, Jim
I had problems with DIVs placed above an INPUT, that cloacked the cursor... and once the DIV was not above it, the cursor appeared back again.
Just an idea: Maybe your IFRAME captured the focus (and/or the keyboard).
I have attached some javascript on onload event of the form. this script contains window.open. Although this works fine in all the browsers window.open doesn't open a new window nor it gives nay error message in google chrome and firefox.
I want to first check the screen resolution if it is less than 1024 then I would open it in a new window without menu,toolbar and others so that the user has more space to work on.
This is a feature, not a bug! :)
remember back in the '90s when pop-up windows annoyed the crap out of everyone? Well, because of the MASSIVE abuse of that JavaScript behavior, now the only way to open windows is with direct user interaction; like a click.
If you have a legitimate reason for opening another window, attach a click event to a button labeled such that it properly indicates you'll be opening a window. If your user wants to open the window, they will do so, and it will correctly get past any but the stupidest popup blockers. If they don't want to, you should not be opening a window in the first place.