Is there a 'valid' solution for the dialog to scroll with the scrollbar instead of still being fixed from the center of the inner window bound ?
There is some situation where the user may have a too small resolution to contain the dialog, and in that case part of the dialog maybe hidden.
You may have a Ok or confirm button in the hidden part, and then the popup may not be closed, nor validated ! Blocking situation.
I tried to change a css into the code from fixed to absolute, and then the dialog scroll with the page: great! But... Meanwhile doing this, opening another popup, do not position it again centered into the layout. Maybe a solution is to recenter the dialog on each onOpen event.
Any help welcome.
The dialog was written to be fixed and as such is not easily changeable.
You could change the position to absolute, but all of the IE hacks will force it to behave as fixed.
In SimpleModal 1.4.2 you can simply set fixed to false:
$('#myModal').modal({ fixed: false });
This worked for us on Chrome and IE all the way back to IE8. (We don't support IE7.)
Related
I've noticed sometimes the keyboard tabbing for focus gets messed up. In this case I am using a Blueprint Dialog component which contains a form to be submitted. The form is built with Redux Form wrapped Blueprint input components. When the dialog first opens I can tab to the concentration field of the form. The next two tabs focus hidden elements (see first image below). Then the "x" to close the dialog is focused, then the concentration field is focused again, and finally I can tab and focus the remaining fields and buttons.
Any tips on how to improve this? Its not clear to me why the pt-overlay-backdrop nor the pt-overlay-content would ever want to be tabbed into. I see they both have tabindex="0".. maybe that should be -1?
Thanks!
Set Dialog's autoFocus to false can fix this issue.
Just using 'mix-blend-mode:overlay' on a text element and it causes my browser to scroll really slow while the text is in the screen view. As soon as you scroll past the text item, the scroll goes back to butter smooth.
The lag effect, which affects both chrome and firefox is solved if I remove the mix-blend-mode.
Has anyone else had a similar problem with mix-blend-mode?
Not sure if this will help you in your case, but I had a 'transform: scale(-1);' set on element that had 'mix-blend-mode' enabled. When I removed the transform the performance was silky smooth! So, if you're using any sort of 'transform' I'd remove it and look for an alternative solution if possible.
It may also help if you set 'isolation' property to the layer beneath, as per example here: https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode#HTML_example
I'm trying to figure a lot of hover/mouseover related CSS/Javascript on a webpage.
To do so, I use Firefox+firebug inspectors.
The problem, is that whenever I move the mouse out of an element I'm inspecting, all the "hover reactions" are lost.
Is there a way, to fix the mouse position firefox sees so I can freely use the mouse withouth concern about weiter it actually hovers some elements or not?
Well, it is not fixing the mouse position, but when you right-click on an element in the Inspector in the regular Developer Tools, you're offered a :hover menu item (along some other things). Selecting that will put the element into permanent :hover state. That at least should cover the CSS-part of your question. I'm sure Firebug offers something similar.
For the JS-part, I'd just set a breakpoint somewhere.
I'm using the latest Firefox testing a fluid layout.
Somehow after the last update of FireFox, I seem to no longer be able to shrink the page width below a certain threshold level (in my case 348px). Even if I delete all elements on the page, I'm still at 348px.
I have tried to hide all toolbars and Firefox buttons, but still no change.
If check a page in Chrome, the HTML width gets reported correctly = whatever my browser window is resized to.
*Question:
Is this a new "feature"/setting? If so, can I turn this off... It's annoying for sure.
Firefox 14 (if I remember correctly) should have a responsive layout tool - you might want to check that out.
I have an image element, following is the html for the button
<input type="image"src="images/undo.png" onmouseover="this.src='images/undo-hover.png'" onmouseout="this.src='images/undo.png'" id="btn_back" onClick="back();" >
When my application makes this input disabled (attribute disabled="disabled") all browsers stop firing mouse events. So I don't get hover images. But opera still keeps firing these event, and I keep getting the hover images on disabled elements.
Can you please try making the INPUT element disabled by default (add disabled="disabled" in the INPUT tag from start). Then see if Opera is still responding to mouse hover. This may not fix the issue right away but will help in figuring out the cause.
Also, another approach could be to call the JS function on mouse event and check if the element is disabled or not. If it is disabled then dont change the src attribute.
HTH,
this is a bug in Opera as we're apparently doing something different than other browsers. Please report it on https://bugs.opera.com/wizard/ and give me the bug ID.
That said, I don't think what you are relying on is standardised anywhere, so possibly you should not write code that depends on this somewhat quirky behaviour. The "disabled" attribute merely means that the element will not do its normal action when clicked. I don't really see any reason why setting disabled should prevent firing mouseover/move. It's easy to check from JS if the button is disabled and not swap the image if it is.
It seems like an expected behavior in opera, Please see the following link.
http://www.quirksmode.org/dom/events/click.html
It says that "A click event on a disabled form field does not fire events in Firefox and Safari. Opera fires the mousedown and mouseup events, but not the click event. IE fires mousedown and mouseup, but not click, on the form. All these implementations are considered correct."
Thanks,
Unnikrishnan B.