Community
Participate
Working Groups
Version: CVS HEAD Steps to Reproduce: 1. Using IE9, load the controls demo. 2. Go to the Browser tab. 3. In the right pane, click the "Go" button for the URL field. 4. Once the page is loaded on the left, drag the sash (between the right and left panes) to the left over some of the content in the page. Particularly the text 'Enabling modular business ...'. 5. Notice the sash stops and dragging is interrupted. This is a rather problematic issue as it prevents resizing of the Browser widget and gives the appearance that the application is broken. This is only reproducible for me in IE9.
I can reproduce it too.
Tested with IE8 and everything is working fine there. Probably related to the "standard" rendering in IE9.
I did some investigation... if you wait for a while and than start dragging the sash, its working fine. Most of the time it's working fine for me. I suppose that it is related to the "blocker div", placed on top of the browser when content is still loading.
(In reply to comment #3) This does not happen in my case. I waited for 5 min. and it is the same. There are spots where the sash will work (when dragging over empty space), but if one drags over content like the text and images, it still breaks. It is especially reproducible if you drag slowly.
(In reply to comment #4) > There are spots where the sash will work (when dragging over empty space), but if one > drags over content like the text and images, it still breaks. It is especially > reproducible if you drag slowly. Yes... you are right. Most of the time I dragged it over the empty space.
This also inhibits shell resizing. In the controls demo, if you resize the shell from the left and drag over the browser text to the right and then without mouseup drag left again, the drag feedback is disturbed. The same works for dragging from the bottom over the text and then back towards the bottom without mouseup.
Any idea how to address this?
Austin, could you explain why you've changed the priority of this bug? We use the priority flag to identify bugs that have to be fixed no matter what [1] and as far as I can see, this bug (even if it's ugly as most bugs are) does not fall into this category. It's not a regression, and it's nothing that compromises the stability of the framework or one of its components. [1] http://wiki.eclipse.org/RAP/Bugzilla
(In reply to comment #8) > Austin, could you explain why you've changed the priority of this bug? We use > the priority flag to identify bugs that have to be fixed no matter what [1] I just thought that P2 was appropriate. According to what is defined in [1], it seems fine. > and > as far as I can see, this bug (even if it's ugly as most bugs are) does not > fall into this category. It's not a regression, and it's nothing that > compromises the stability of the framework or one of its components. > > [1] http://wiki.eclipse.org/RAP/Bugzilla I guess I wasn't aware of the further criteria you mentioned above. I just see this as a major loss of functionality with a very commonly used widget in a browser that many people use. So it makes sense that we should try to address it before the release. I have been working on this for a while, and I don't have any idea where to address this, since it really has to do with client-side event propagation.
I'm sorry to contradict, but this is not enough to prioritize a bug. This issue doesn't crash any application, and it doesn't affect every application, only those which use a Sash combined with a Browser. Moreover, it is not a regression, it does not affect our API, neither is it a security problem. In my eyes, those would be reasons that justify a prioritization. This issue is a loss of functionality in certain constellations. If we used this as a criterion for prioritization, we'd probably have to prioritize half of our open bugs. Since this is far more than we can handle in this timeframe, this would render the priority flag useless. Please don't get me wrong on this, Austin: If you're going to work on this bug and make it "your" priority, you'll have our support. But it's currently not a priority for us.
(In reply to comment #10) > I'm sorry to contradict, but this is not enough to prioritize a bug. This > issue doesn't crash any application, and it doesn't affect every application, > only those which use a Sash combined with a Browser. Moreover, it is not a > regression, it does not affect our API, neither is it a security problem. In > my eyes, those would be reasons that justify a prioritization. > > This issue is a loss of functionality in certain constellations. If we used > this as a criterion for prioritization, we'd probably have to prioritize half > of our open bugs. Since this is far more than we can handle in this timeframe, > this would render the priority flag useless. You are not contradicting me, ;-). I just was not aware of the team's "real" criteria for prioritization. Perhaps you should add what you just mentioned to the wiki page so that everyone can be on the same page. > Please don't get me wrong on this, Austin: If you're going to work on this bug > and make it "your" priority, you'll have our support. But it's currently not a > priority for us. I am a little confused about this. My intent was not to prioritize the bug to imply that you all need to fix it. As I said, I have been working on this bug for some time. I just thought it was the right prioritization. At first read of your comment, I thought that what you were implying is that the prioritization flag is only for things that EclipseSource RAP team members agree to make a priority, but I don't think that is what you meant. What I do think that you mean is: Given that a bug does fit the team's prioritization scheme (which should be made more clear), I can elevate the priority of a bug for the team. But if you as the co-lead don't agree that it fits the criteria, then that doesn't necessarily equate to a practical priority to anyone other than myself so the prioritization should be lowered. Or should you be the only one to raise the priority? I am fine with that, I think that there are just some unwritten rules that most of the team has followed in the past due to being co-located and that just need to be externalized.
(In reply to comment #11) > You are not contradicting me, ;-). I just was not aware of the team's "real" > criteria for prioritization. Perhaps you should add what you just mentioned to > the wiki page so that everyone can be on the same page. You're right. I've added the criteria mentioned above to the wiki page. Actually, those rules are still developing. It's not so long ago that we decided to use this attribute at all. > I am a little confused about this. My intent was not to prioritize the bug to > imply that you all need to fix it. As I said, I have been working on this bug > for some time. I just thought it was the right prioritization. Ok. I'm sorry if I over-reacted. I was not sure what you meant by changing this flag and may be I'm a bit touchy when it comes to requests for fixes - because we just get too many of them ;-) > priority of a bug for the team. But if you as the co-lead don't agree that it > fits the criteria, then that doesn't necessarily equate to a practical priority > to anyone other than myself so the prioritization should be lowered. Or should > you be the only one to raise the priority? Not at all. Actually, I believe it's better for a team to follow rules than a dictator. All I want to say is that the attribute should reflect the priorities of the team and that usually we agree on bugs to prioritize. I didn't communicate this well, my apologies. But now let's talk about possible fixes. What did you try so far and why doesn't it work?
(In reply to comment #12) You are a good team lead. :-) I will be out of the office this week for spring break, so I will get back to you next week on this.
I have confirmed that Sash.js is not receiving mousemove events when the sash is dragged over the content described above. I am still at a loss as to what is the cause. Things I have tried: I have checked to see if it was a DOCTYPE or http-equiv issue in the browser widget's target html. I have tried adding a dragover event. I have tried adding the event listeners to the client document instead of the sash. Here are some resources I have been utilizing: http://www.mail-archive.com/qooxdoo-devel@lists.sourceforge.net/msg04260.html http://stackoverflow.com/questions/5261328/javascript-receive-mousemove-events-from-iframe-too http://stackoverflow.com/questions/5645485/detect-mousemove-when-over-an-iframe http://stackoverflow.com/questions/5855135/css-pointer-events-property-alternative-for-ie http://www.vinylfox.com/forwarding-mouse-events-through-layers/ With regard to the sash widget, my suspicion is that the qooxdoo implementation of setCapture() is not working properly for IE9 iframes.
(In reply to comment #14) > I have confirmed that Sash.js is not receiving mousemove events when the sash > is dragged over the content described above. I am still at a loss as to what is > the cause. Okay, i haven't read all the links you posted, but i'm quite confident that i know whats going on. Dom events from within an iframe are never propagated to its parent frame. When you move the mouse very slowly, the move events all get captured by the sash itself, becausee it's moved with the mouse. If you move too fast, you end up hovering the iframe. The iframe gets the move event and thats the end of the story. The only crack in my theory is that it works in other browser. I would guess that ie9 is skipping pixels while firing move events and others don't. Ie7/8 do whatever they want anyway.
(In reply to comment #15) > Okay, i haven't read all the links you posted, but i'm quite confident that i > know whats going on. Dom events from within an iframe are never propagated to > its parent frame. When you move the mouse very slowly, the move events all get > captured by the sash itself, becausee it's moved with the mouse. If you move > too fast, you end up hovering the iframe. The iframe gets the move event and > thats the end of the story. Actually, in IE9 the move event is propagated when the drag occurs in *whitespace* within the iframe. But when dragging over content like text elements, it ceases to propagate. > The only crack in my theory is that it works in other browser. I would guess > that ie9 is skipping pixels while firing move events and others don't. Ie7/8 do > whatever they want anyway. I agree. It is puzzling that the bubbling works in other browsers and in IE9 over *whitespace*. In EventHandler.attachEventTypes() I have tried to register events using the document instead of the body for IE9 only and did not see any difference in behavior. Could it be that for IE9 we have to implement the behavior described in [1]? [1] http://stackoverflow.com/questions/5261328/javascript-receive-mousemove-events-from-iframe-too
(In reply to comment #15) > When you move the mouse very slowly, the move events all get > captured by the sash itself, becausee it's moved with the mouse. If you move > too fast, you end up hovering the iframe. The iframe gets the move event and > thats the end of the story. I confirm this. I definitely can reproduce that if you grab the sash handle on the right side and drag left slowly then the sash will receive the events. And if you grab the sash handle on the left side and move left you will not receive events ( because the sash handle is not moving before the mouse). Any more thoughts? I am out of any.
OK, here is my last thought for today. This could potentially happen for dialogs and other draggable items if the mouse ends up moving over an iframe during a drag. But I think the lightbox div prevents it from happening in most cases. Perhaps a solution is to shim a transparent div over iframes during a sash drag?
(In reply to comment #18) > cases. Perhaps a solution is to shim a transparent div over iframes during a > sash drag? Probably the only method that would work in all cases. But it would have to happen on ALL iframes on ALL drag operations. Its going to be somewhat complicated.
The browser can be blocked by such a div if you call Browser#setEnabled(false). Can we use this somehow?
(In reply to comment #19) > Probably the only method that would work in all cases. But it would have to > happen on ALL iframes on ALL drag operations. Its going to be somewhat > complicated. If we just implement it for sash, then it should be simple enough. If upon mouse down of the handle, we check all siblings and their children for iframes then we can shim (or disable) them. Upon mouse up we remove the shim (reneable). The real trick is that we would have to keep track of the iframes we modify because we don't want to enable something that the end-developer disabled on the server-side. What do you think about that approach?
(In reply to comment #21) I can come up with an initial patch if you think the approach is good.
I ran into a similar issue once again while wrapping an existing javascript component (CKEditor) for RAP. It consumes drag-relevant events like mouseup, and there is currently no way to fix it without hacking the original code. I could imagine a global event fired whenever any drag operation starts/stops, and widgets like Browser could use this to somehow configure themselves to not consum events (e.g. by hiding, overlays, etc).
