Closed qx-bug-importer closed 8 years ago
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
Flash movie
This Flash movie is needed to run the code snippet.
ERROR: no way found to migrate TestFlash.swf (application/octet-stream) from bugzilla.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
Founded two bug reports by Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=90268 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=262354 [2]
[1] Describes that using the style attribute "display" occurs the reload, but using the style attribute "visibility" not. The error also occurs if one parent node from the plug-in using the "display" attribute.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
HTML file
This file shows the issue without using qooxdoo.
index.html (text/html)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Flash</title>
<script type="text/javascript">
var visible = true;
//var style = {name: "display", hidden: "none", visible: ""};
var style = {name: "visibility", hidden: "hidden", visible: "visible"};
function hideOrShow() {
var element = document.getElementById("node");
if (visible) {
element.style[style.name] = style.hidden;
visible = false;
} else {
element.style[style.name] = style.visible;
visible = true;
}
}
</script>
</head>
<body>
<div id="node">
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
id="flash" width="400px" height="200px"
codebase="http://fpdownload.macromedia.com/get/flashplayer/current/swflash.cab">
<param name="movie" value="TestFlash.swf">
<embed src="TestFlash.swf" width="400px" height="200px" name="flash"
type="application/x-shockwave-flash"
pluginspage="http://www.adobe.com/go/getflashplayer">
</embed>
</object>
</div>
<input type="button" value="hide/show" onclick="javascript:hideOrShow()">
</body>
</html>
Christian Hagendorn (@Hagendorn) wrote:
Accepted.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
Using the style attribute "visability" instead of "display" in "qx.html.Element" could fix the issue.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
Used the style attribute "visibility" with value "hidden" instead of "display" with value "none".
Fixed this with reversion 19152 in trunk, but I leave the bug as opened to monitor if negative effects occurs.
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
Sorry, Christian, but I do not think this is something which could be done. Visibility needs to be applied via "display" as this also removes the element from the document flow. If the Flash class has an issue here this should be fixed locally for the flash class maybe by changing the implementation so that it moves the element out of the viewport etc. Not sure.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
Sebastian, please have a look to comment #2, I added some links that describes the problem. When a node from the DOM is changing the "display" attribute, than all plug-ins, which are a child node from the tree structure, are reloaded.
I talked to Fabian, about the general problem from using the "display" instead of the "visibility" attribute. The result was that there is no other possibility to solve this issue, because setting a parent widget (from the Flash widget) with calling hide() also reload the Flash movie.
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
But visibility is no solution. It may fix the issue but it is like fixing 10% while breaking 90%. This is nothing we can do IMHO ;)
I am still not sure though if the reload of the flash movie is an issue at all. Can someone with Flash background explain why this is an issue. IMHO this is some kind of browser-side optimization which is quite logical. So what is a good reason to torpedate this optimization? Reloading is normally not an issue as the data is cached already. Do I overlook something here?
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
> But visibility is no solution. It may fix the issue but it is like fixing 10% > while breaking 90%. This is nothing we can do IMHO ;)
Yes, I quite agree with you. But I think that this isn't so extreme in this case ;)
I tested this fix local since last Monday and committed this today. The bug is still open to have the fix on the radar. If the fix isn't right, it will be removed.
> I am still not sure though if the reload of the flash movie is an issue at all. > Can someone with Flash background explain why this is an issue. IMHO this is > some kind of browser-side optimization which is quite logical. So what is a > good reason to torpedate this optimization? Reloading is normally not an issue > as the data is cached already. Do I overlook something here?
I have an internal feature request for this issue, so I think it should be fixed.
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
Christian, you know of the difference of visibility and display, do you? This is a major change in how this low-level layer behaves. Ever thought about the consequences on the low-level layer? Currently this changes breaks my whole UI layer which is based on qx.html.Element (low-level mobile UI toolkit).
> I have an internal feature request for this issue, so I think it should be > fixed.
This do not answer my question, though. That it should be fixed is quite logical. The question remaining is the "where it should be fixed". :) The code in qooxdoo uses the native browser behavior. Before working around this behavior, which makes some sense in this case, one need to argue why this is a problem in the application you have in reference. So please tell me why this is a problem for the flash movie when it's being reinitialized.
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
I would be think of some kind of property on a widget which needs to be made visibility:hidden instead of display:none. For example when a tab page contain a flash movie somewhere, this flash movie might be hidden dynamically when navigating through the tabview. There should be a property which marks this tab page as being processed with "visibility" instead of "display". This is something the user needs to know though, but IMHO this is the best - most local solution - which could be found. And it do not break the previous behavior.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
> > Christian, you know of the difference of visibility and display, do you? This is > a major change in how this low-level layer behaves. Ever thought about the > consequences on the low-level layer? Currently this changes breaks my whole UI > layer which is based on qx.html.Element (low-level mobile UI toolkit).
Yes, I know the difference, thats why I have talked to Fabian about it and thats why I have done it. I talked also with Alex (before I have known your problems, sorry for braking your code) and we decided to reverted the last changes temporary. (Done with Reversion 19160)
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
> I would be think of some kind of property on a widget which needs to be made > visibility:hidden instead of display:none. For example when a tab page contain a > flash movie somewhere, this flash movie might be hidden dynamically when > navigating through the tabview. There should be a property which marks this tab > page as being processed with "visibility" instead of "display". This is > something the user needs to know though, but IMHO this is the best - most local > solution - which could be found. And it do not break the previous behavior. Thank you for sharing your idea, that could be a possible solution. :)
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
Cool that you like it. It also means that we fix the edge case with a edge case hint for the layouter instead of modifying the whole behavior.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
[For documentation purposes] Tried to move the movie out and back to the viewport -> this reload (reinitialize) the movie. Changing the parent DOM node dynamically (set to body and back to the old parent) -> also reload the movie.
It seems to me that the possible solution, must use the style attribute "visibility" to fix the issue, other solution is not possible.
qx-bug-importer
commented
15 years ago Christian Hagendorn (@Hagendorn) wrote:
I talked again with Fabian about the problem. When discussing a possible solution, we found out that the behavior from the method hide() on qx.html.Element and on qx.ui.core.Widget is implemented different.
hide() on qx.ui.core.Widget set the widget to invisible, but surrounding content has there old position and size. hide() on qx.html.Element set the element to invisible, but surrounding content change there position.
Fabian and I agree that the different behavior should be changed. The hide() on qx.html.Element should also have the same behavior like qx.ui.core.Widget, that means that surrounding content should never change there position and/or size.
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
Christian, yes this issue was already seen somewhere during developing 0.8. Though it is not that criticical as in most js libraries (aka jQuery, prototype, ...) "hide" really results into display=none (remove from layout) and this way qx.html.Element covers these. If we really want to modifiy this behavior (which is a major change in the behavior - at least for low-level users) - we should add the "exclude" method as well so that elements might be removed from the document flow like widgets.
One thing also should kept in mind is that visibility:hidden elements are part of the reflow in all browsers. They are modified (computed sizes) when the outer dimensions change etc. To change the default in qooxdoo and use visibility instead of display - even if feasible in first instance - might mean that all hidden elements are always relayouted. Something not happended ever before in qooxdoo.
Also keep in mind that elements which are display:none are somewhat cleared from memory. This is easily detectable in mobile browsers but I remember that this is the same for desktop browsers as well. This means that display:none might be more efficient for the browsers - at least when the elements are kept invisible for at least a few seconds.
Also think about Windows in an application like the feedreader. When you hide windows using visibiliy:hidden they are kept in place where they where shown before. This means that they act like a blocker which sits between the (visible) background and the cursor which interupts clicks as it lead to clicks on the wrong target. This is especially critical for canvas layouts where children may overlap each other. But this may also be problematic for others like box-layouts where the now-hidden widgets is rendered on the old coordinate (just invisible) and may overlap another widget which is visible but somehow placed behind the invisible one (maybe using a higher zIndex or placed after the other one in the DOM children structure)
The only solution I could think of is a special exclusion mode for widgets which is controlled by a property like mentioned in comment #12. As this is still quite an edge case I think that this is a quite powerful and easy to use workaround.
qx-bug-importer
commented
15 years ago Fabian Jakobs (@fjakobs) wrote:
> Christian, yes this issue was already seen somewhere during developing 0.8. > Though it is not that criticical as in most js libraries (aka jQuery, > prototype, ...) "hide" really results into display=none (remove from layout) > and this way qx.html.Element covers these. If we really want to modifiy this > behavior (which is a major change in the behavior - at least for low-level > users) - we should add the "exclude" method as well so that elements might be > removed from the document flow like widgets.
It doesn't really matter what jQuery does when calling hide. It is much more important to be consistent within the framework. We decided to distinguish between "show" and "exclude" in the widgets. Since qx.html.Element has these two functions as well they naturally should have similar semantics. As Christian noted this is currently not the case. If you want the old behavior in qx.html.Element just use exclude.
> One thing also should kept in mind is that visibility:hidden elements are part > of the reflow in all browsers. They are modified (computed sizes) when the > outer dimensions change etc. To change the default in qooxdoo and use > visibility instead of display - even if feasible in first instance - might mean > that all hidden elements are always relayouted. Something not happended ever > before in qooxdoo.
It is true that hidden elements are considered to be relayouted but since all widgets are positiononed absolutely and have fixed sizes there is not much to reflow. From the browser's view there is nothing to dynamically recompute.
> Also keep in mind that elements which are display:none are somewhat cleared > from memory. This is easily detectable in mobile browsers but I remember that > this is the same for desktop browsers as well. This means that display:none > might be more efficient for the browsers - at least when the elements are kept > invisible for at least a few seconds.
The memory cleaning is one of the biggest problems with this approach. It causes e.g. Java applets to reload and break the external interface of Flash. It is the main reason to change this behavior.
> Also think about Windows in an application like the feedreader. When you hide > windows using visibiliy:hidden they are kept in place where they where shown > before. This means that they act like a blocker which sits between the > (visible) background and the cursor which interupts clicks as it lead to clicks > on the wrong target. This is especially critical for canvas layouts where > children may overlap each other. But this may also be problematic for others > like box-layouts where the now-hidden widgets is rendered on the old coordinate > (just invisible) and may overlap another widget which is visible but somehow > placed behind the invisible one (maybe using a higher zIndex or placed after > the other one in the DOM children structure)
This would be a blocker if it was true but in my tests hidden elements do not block mouse events. I have tested your scenario in FF3, WebKit, IE8 and Opera and none blocks the mouse events. I would be very interested in situations, where this could happen.
> The only solution I could think of is a special exclusion mode for widgets > which is controlled by a property like mentioned in comment #12. As this is > still quite an edge case I think that this is a quite powerful and easy to use > workaround.
This special casing is not an option since not only hiding the flash widget is a problem. We get into trouble if any of the parent widgets is hidden, which is really hard to catch.
If we don't encounter further problems we'll switch to use the visibility style to hide widgets.
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
(in reply to comment #19)
> It doesn't really matter what jQuery does when calling hide.
I don't think so. It's not that important to force all API in a framework - even if used in completely different areas - to be (somewhat) identical. IMHO the most important thing is that an API makes sense for the cases where it might be used. In best possible, most intuitive style. If the established way other DOM-level APIs implement this, it might not be the worst choice to implement it the same way.
I would like to suggest here to keep the modification of qx.html.Element out of the scope of this bug and open another one here if necessary. The "visibility" vs. "exclude" in qx.html.Element is another topic in my opinion. If this is OK, please tell me so and I am helping out here.
> If you want the old behavior in qx.html.Element just use exclude.
I like to add here that "exclude" is also not identical between "qx.ui.core.Widget" and "qx.html.Element". The "Element" is being removed from the DOM, not simply ignored during layout. This might result into completely different behavior.
> From the browser's view there is nothing to dynamically recompute.
Without having a paper which supports my knowledge here, I think that this might be true in theory but is still wrong in the practise. Even absolute positioned elements react on some changes on the page. And not every browser do such a optimization for absolute placed elements - even if possible (and logical).
> The memory cleaning is one of the biggest problems with this approach.
But this is also a huge benefit as multi-page or multi-windows applications dramatically benefit from this behavior of cleanup. In most cases I can think of this makes perfectly sense and do not result in any bad side effects (qooxdoo has worked long without this being ever figured to problem). IMHO Firefox 2 do not had this behavior, but Firefox 3 added this for improve memory consumption. In general I would like to not work-around the browser optimization here.
Sure it might be helpful for some plugins to change this behavior. The question here is, if the edge case (of having plugins which have issues of correctly reloading and recovering) is more important, than the overall scalability of the widget system. In my opinion this is not the case.
> This would be a blocker if it was true but in my tests hidden elements do not > block mouse events. I have tested your scenario in FF3, WebKit, IE8 and Opera > and none blocks the mouse events.
Wow. This is really impressive. Just build an example myself as I do not thought this works. But you are right. Man, I would have bet on a box of beer regarding this.
> This special casing is not an option since not only hiding the flash widget is > a problem. We get into trouble if any of the parent widgets is hidden, which is > really hard to catch.
I understood this already. But something which is also clear is that if you use Flash or Java or whatever other problematic plugin and you see this problem (this is the important thing) you might switch the parent elements which are togglable (e.g. a tabview, a window, etc.) to use "visibility" instead of "display". This way the problem could fixed as part of the application and not with a major modification to the framework.
Sure this means a little more understanding by the application developer, but you get the best of both words:
In the documentation of such a problematic widget one could explain it like this:
"If you put this widget in any type of widget which is toggled regarding visibility in your application you need to setup this widget so that it uses "visibility" instead of "display" to hide the element at DOM-level. Otherwise the browser memory managment automatically cleanup these elements which lead to a reinitialization when showing the widget again."
What do you think about this?
qx-bug-importer
commented
15 years ago Fabian Jakobs (@fjakobs) wrote:
OK, we are both assuming things without any proofs.
I assume:
You assume:
using "display:none" instead of "visibility:hidden" saves memory
Both sound plausible but we shouldn't dismiss an option because we assume something. We should rather find a way to test these assumptions.
For the display vs. visibility issue we could create a qooxdoo application with a tab view. The tab view should have a large number of tabs, each containing some widgets. Switching between the tabs and observing the memory consumption should give us some hints.
Testing the reflow issue is a bit harder. Any ideas?
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
You are right Fabian, some sources and evidence should help here. I am happy that we can wait for some facts before applying such a major change to the groundwork of qooxdoo.
Mozilla wrote about the improvements of Firefox 3 once (http://blog.pavlov.net/2008/03/11/firefox-3-memory-usage/). They also mention things like memory cleanup of uncompressed images etc. In my opinion these thing where not applied that drastically in Firefox 2. It might be interesting if this Flash issue is also present in Firefox 2. The Flash issues might be a side-effect of this new memory managment.
This seems to be related to this issue. I assume that the report is from the pre-Firefox 3 era so that the author mentions that this issue is not existent in Firefox:
Interestingly he uses visibility and still has the problem in IE. Has this already been tested by you? Hopefully using visibility do not break IE then.
Another post found in Google also using visibility: http://www.discussweb.com/flash-actionscript-programming/5420-losing-externalinterface-callbacks-ie-when-flash-hidden.html
qx-bug-importer
commented
15 years ago Sebastian Werner (@swernerx) wrote:
Regarding reflow performance: In Firefox there is a new event which report about "painting" (not sure about the name at the moment) when it happens. Not sure though if this helps anyhow.
Another resource regarding the Flash issue (at the moment created IE6 specific): http://bugs.adobe.com/jira/browse/FP-143
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
Added a native example for using "display:none" and "visibility:hidden". This test can be used to test the performance and memory usage for each variant. These test is committed to the qooxdoo-contrib repository. Link: https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/Bugs/2367/testmemnative/test.html
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
Result form the performance tests
This document shows the result from the two performance tests.
The first test adds different number of elements to a node (parent) and hides only this node with "display:none" or "visibility:hidden".
The second test adds also different number of elements to a node (parent), but hides each added element with "display:none" or "visibility:hidden".
The code could be found in the test directory from the bug. (https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib/trunk/qooxdoo-contrib/Bugs/2367/testmem/)
ERROR: no way found to migrate Result from the performance tests.pdf (application/octet-stream) from bugzilla.
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
These tests show that it isn't critical to use "visibility:hidden". Some browser are faster with "display" and some are faster with "visibility", but the difference between both are minimal.
I also coudn't detect any memory issues with "visibility".
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
Christian, interesting approach. I am not sure how well these benchmarks are really help here. These rendering aspects are quite complex in todays browsers. Not sure if the timeout in your code is helpful. This is mainly useful for the JavaScript engine but does not say anything about the rendering engine.
I am currently in contact with some guys from Mozilla and Webkit to give me some insights regarding performance and memory efficience of these two style properties. There need to be a major difference. Otherwise it would not explain the effect you see with the Flash movie.
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
> Christian, interesting approach. I am not sure how well these benchmarks are > really help here. These rendering aspects are quite complex in todays browsers. > Not sure if the timeout in your code is helpful. This is mainly useful for the > JavaScript engine but does not say anything about the rendering engine. Yes, my intention was to get the rendering time from the engine. I think that using a timeout is the trick in this case. It seems to me that the code from the timeout is running first when the rendering engine is finished. If I use no timeout, it seems to me that I only time the duration from the JavaScript engine and this is by far lesser than with timeout.
The only problem is that the performance test is not really complex. The question is, what happens with a real qooxdoo application. But for this we need a test. What do you think is a good test case for this?
> I am currently in contact with some guys from Mozilla and Webkit to give me > some insights regarding performance and memory efficience of these two style > properties. There need to be a major difference. Otherwise it would not explain > the effect you see with the Flash movie. Yes sure. I'm all on edge from the feedback.
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
Normally when you would like to force the engine to render you ask for offsetWidth etc. as this is the computed layouted size an element have. In all browsers this results into a layouting. The timeout is basically placed where the JS engine is done with it's work, but it need not to be related to the rendering engine. Often these are two separate things.
I will keep you posted through this bug regarding the feedback from the browser developers.
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
Changed display:none to visibility:hidden with revision 19726. This is done to test the effect with the nightly test infrastructure.
If there are any problems, you can revert the change by changing the line 280 on qx.html.Element from: obj.element.style.visibility = obj.visible ? "" : "hidden"; To: obj.element.style.display = obj.visible ? "" : "none";
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
Changed unit test with reversion 19727 to pass visibility:hidden.
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
This again breaks my application. Do we really need to change a behavior in qx.html.Element to fix some rare issue which is layers on-top of this? My vote still goes for a special property which switches the hide mechanism locally to visibility instead of display. This means some manual work for the people how have issues with the old behavior but keeps all things compatible to the original implementation. There might also people for whom it's perfectly OK to reload such a Flash movie. The reload basically means that the browsers clears out invisible Flash movies from memory which might be wanted in some applications (think about a movie browser, for example).
Please tell me if I can help to explain my idea further. I am currently not sure, if you have understand what I mean, so I might explain it a little more.
qx-bug-importer
commented
14 years ago Tino Butz (@tjbutz) wrote:
Hi,
Unfortunately this fix breaks the appear event:
qx.event.handler.Appear -> refresh method Line 180:
var displayed = elem.offsetWidth > 0; if ((!!elem.$$displayed) !== displayed) ....
This check won't work with your fix as the offsetWidth won't be 0.
qx-bug-importer
commented
14 years ago Andreas Ecker (@ecker) wrote:
Johnny is currently looking into the issue ...
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
Retrying to discuss this topic. It seems my comments are not processed. This makes me a bit frustrated. Again, why modify this when a simple property on a Widget might be enough and leave the control over the behavior completely to the application developer (I still think that the requirements here might differ from application to application).
qx-bug-importer
commented
14 years ago Jonathan Weiß (qooxdoo-bugs) wrote:
> Reloading is normally not an issue > as the data is cached already. Do I overlook something here?
The problem is that all plug-ins (I tested Flash, Silverlight and Java applets) are restarted when changing display to "none" and then back to "block". These happens in all browsers but Internet Explorer. We are thinking about handling DOM trees with an object-tag in it differently and go back to using display instead of visibility.
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
Regarding comment #36: But Jonathan, could not it be the case that this reloading does not negatively effect most applications? Otherwise this would be a topic for most other JS frameworks and applications as well. I still think that we are talking about a generally welcome feature of the browser: To better deal with invisible (and unrendered which is not the case for visibility:hidden as offsetHeight etc. still returns valid values) elements regarding their memory consumption. Otherwise, from the perspective of the browser vendor/developers, this whole behavior would not make a lot of sense. Why should they deal so, when there is no benefit to do so?
qx-bug-importer
commented
14 years ago Jonathan Weiß (qooxdoo-bugs) wrote:
> Regarding comment #36: > But Jonathan, could not it be the case that this reloading does not negatively > effect most applications?
I was told that this behavior has a negative impact on applications... But perhaps it is possible to avoid this problem by adding Flash objects which must run all the time into elements that never get invisible.
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
In reply to comment #38:
No Jonny, I think it may be a problem for applications, but it also may be ok for other applications. I don't think that it's a huge issue in general, as otherwise we had heart from such an issue in other frameworks as well. I think this is some kind of browser optimization which applies here and this is maybe a thing we do not like. This also affects basic DOM applications - e.g. apps using jQuery.
As I suggested a few comments ago it might be cool to simply have a control over the behavior instead of forthing the one or another. Just keep it as a default as it was (using display:none) and add a property to Widget.js which allows controlling this behavior. In the affected applications it should not be to complicated to configure the areas accordingly which are affected by this issue.
For example, when the Flash movie is part of a TabView it, which itself is placed in a Window:
window.setAlternativeHide(true); tabView.setAlternativeHide(true);
These two lines basically fix the issue for such an case - if implemented. What do you think?
I think that qx.html.Element should also be usable without a widget system. In the case where I use it we do not work with all absolute positions and this way visibility:hidden still has an effect to the layout. The switch to "visibility" basically omits the usage of the "qx.html" layer in low-level applications.
qx-bug-importer
commented
14 years ago Matthew (matthew+qooxdoo) wrote:
Hi All, Bit late joining this dicussion because up until now because it didn't affect me until recently. (I reported BZ#2686)
We have something that is similar to a SplitButton/MenuButton, when the menu is opened we keep the "pressed" state and then when the menu fires the disapear event we remove the state. This is broken unless we change the framework.
We have no interest in using browser plugins so I won't comment on that issue but I would like to at least see a global option that could revert this change.
if (foo) { obj.element.style.visibility = obj.visible ? "" : "hidden"; } else { obj.element.style.display = obj.visible ? "" : "none"; }
qx-bug-importer
commented
14 years ago Jonathan Weiß (qooxdoo-bugs) wrote:
> For example, when the Flash movie is part of a TabView it, which itself is > placed in a Window: > > window.setAlternativeHide(true); > tabView.setAlternativeHide(true); > > These two lines basically fix the issue for such an case - if implemented. What > do you think?
I really like this idea. Have you thought about setting this property automatically if a plug-in is added into a container?
> I think that qx.html.Element should also be usable without a widget system. In > the case where I use it we do not work with all absolute positions and this way > visibility:hidden still has an effect to the layout. The switch to "visibility" > basically omits the usage of the "qx.html" layer in low-level applications.
Agreed.
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
Jonny, I have no idea how you would do this automatically. But even if, I would not like it because it adds addional magic here.
qx-bug-importer
commented
14 years ago Andreas Ecker (@ecker) wrote:
Oops, there was a mid-air collision that I didn't notice, when I initially tried to add the following info a few days back:
We're about to revert to the previous default behavior (see comment 30), particularly due to problems of the more general solution with (dis)appear events, see comment 33.
qx-bug-importer
commented
14 years ago Jonathan Weiß (qooxdoo-bugs) wrote:
.
qx-bug-importer
commented
14 years ago Jonathan Weiß (qooxdoo-bugs) wrote:
I reverted to the previous default behavior in r19848.
qx-bug-importer
commented
14 years ago Jonathan Weiß (qooxdoo-bugs) wrote:
Out of 0.8.3 timeframe.
qx-bug-importer
commented
14 years ago Andreas Ecker (@ecker) wrote:
Lowered severity back to normal to account for the real scope of the issue. I think it could/should be addressed for those plugins (particularly Flash) specifically. But I'm even inclined to reduce it down to "enhancement" here, since the reload seems to be the regular behavior of such plugins. Johnny, Chris, comments?
qx-bug-importer
commented
14 years ago Andreas Ecker (@ecker) wrote:
Also since there hasn't been some more reports/comments, I correctly marked this issue as enhancement, target unspecified. It could also be set to WONTFIX, as it might not be an often used (even expected) behavior. Comments?
qx-bug-importer
commented
14 years ago Christian Hagendorn (@Hagendorn) wrote:
I would also prefer to set this issue to WONTFIX, due to this is a browser behavior and it should be possible to react on reload (perhaps sync state over External Interface or something like that).
qx-bug-importer
commented
14 years ago Sebastian Werner (@swernerx) wrote:
I would also prefer WONTFIX. At the moment it is not directly tellable that a change here might be an improvement. So this should maybe done in a separate issue as soon as one has a brilliant idea :)
Christian Hagendorn (@Hagendorn) wrote:
If the Flash widget is set to hidden and afterwards to visible the loaded Flash movie is reloaded. It seems that the IE 7 is not affected with his issue, but FF 3.0.10, Opera 9.63, Safari 3.2.2 and Chrome 1.0.154.43 reload the Flash movie.
This code snippet reproduce this issue:
var button = new qx.ui.form.Button("First Button"); button.addListener("execute", function(e) { if (flash.isVisible()) { flash.hide(); } else { flash.show(); } });
var flash = new qx.ui.embed.Flash("testflash/TestFlash.swf").set({ width: 300, height: 200 });
var doc = this.getRoot(); doc.add(button, {left: 50, top: 50}) doc.add(flash, {left: 50, top: 100});
assigned to Jonathan Weiß (qooxdoo-bugs)