This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
On the new (released 1 weeks ago), there seems to be problem when using inspect mode on page after scrolling. To reproduce: - run some HTML5 project in mobile Safari (tested on iOS device) - start inspect mode - click on some element in browser => element is highlighted in browser OK - scroll page - click on some element in browser => highlighting in browser is off, it seems like it cannot handle "offset" caused by the scrolling. For instance, if I click on element that is in 1/2 of visible page are (without any scrolling yet), it is highlighted OK. But if I scroll a bit and click on the same element again, the highlight is placed on its original position on page/display as before scrolling. When this happens, IDE does correctly recognize selected element either way. So the issue is only with painting highlighting in browser. This makes inspect mode in mobile Safari very confusing. Please evaluate, I think this is a stopper for 7.4 Product Version: NetBeans IDE 7.4 RC2 (Build 201309252201) Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b14 System: Mac OS X version 10.8.4 running on x86_64; UTF-8; en_US (nb)
Here is a video with this issue https://docs.google.com/file/d/0B6Sd5ov8j7IUTUt5UUJsWFVlajA/edit?usp=sharing I was clicking on 2 elements, the title Welcome and blue button below. I have old iOS6 in Simulator and this issue is not happening there
...the same happens with Cordova project.
The problem seems to be in inspection.js. Honzo how painting is supposed to work during scrolling? When I scroll on iOS 7, dashedLine is painted to the same coordinates . Should be canvas moving and elements should have fixed positions or canvas should have fixed position and elements are moving?
The canvas is fixed. The coordinates used for painting on the canvas are obtained using element.getClientRects(). This method is supposed to return coordinates relative to the viewport, i.e., relative to the canvas. And that's how it works in Chrome/FF/IE. Unfortunately, there seems to be some problem with this method on iOS7. Could you, please, try the following code snippet: <!DOCTYPE html> <html> <body style="width: 2000px; height: 2000px"> <div style="position: relative; top:100px; left:200px; background-color: red; width:50px; height:20px"></div> <script> handler = function() { var element = document.getElementsByTagName('div')[0]; var rects = element.getClientRects(); alert(rects[0].left+" "+rects[0].top); } </script> <button onclick="handler();">Press</button> </body> </html> There is a button that displays an alert with the client rectangle of the red DIV. Try to press it, scroll the page a bit (to move the DIV within the viewport) and then press it again. The displayed values are supposed to be different but I guess they may be the same on iOS7.
Yes, it always returns 208 x 108 no matter how I scroll the page
> Yes, it always returns 208 x 108 no matter how I scroll the page Thank you for the test. This is clearly a bug in Safari on iOS7. We can modify the calculation to consider this bug but I am afraid that it may get fixed one day and our calculation will be incorrect again. Anyway, could you, please, perform the same test again with the following version of the alert: alert((rects[0].left-window.pageXOffset)+" "+(rects[0].top-window.pageYOffset)); Does it show different values (i.e., the coordinates of the element in the viewport) by now?
(In reply to Jan Stola from comment #6) > > Yes, it always returns 208 x 108 no matter how I scroll the page > > Thank you for the test. This is clearly a bug in Safari on iOS7. We can > modify the calculation to consider this bug but I am afraid that it may get > fixed one day and our calculation will be incorrect again. Yes. I was writing the same comment. We can workaround it, and this workaround will break with fixed version of iOS.
(In reply to Jan Stola from comment #6) > Does it show different values (i.e., the coordinates of the element in the > viewport) by now? Yes, for instance once the red div is out of viewport, it returns 208 x -110 Just to be thorough, I've slightly modified the HTML above otherwise I had almost no scrolling on iPad. I've just added some new lines, e.g.: ... </script> <br/><br/><br/><br/><br/><br/><br/><br/><br/><br/> <button onclick="handler();">Press</button> ...
I don't know how Safari is being versioned and updated, but could another option be to workaround it only for this Safari version? window.navigator.appVersion returns in my case 5.0 (iPad; CPU OS 7_0_2 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A501 Safari/9537.53 Of course if Safari gets updated and the update wouldn't contain fix for this, it would be broken again...
spent sime time on google to find out, what javascript developers do in this case. And they are sometimes forced to do really ugly things. For instance this: we can create some fake element. Put it somewhere, scroll +1px. GetClientRect and detect, if coordinates were moved. Scroll -1px. And based on this test we can enable/disable workarounds. But this is really ugly. I don't know if we want to do it. Other option is to detect iOS 7 -> Implement workaround. And when this bug appear again with new iOS7 update we will just remove the workaround with NB patch. Or we can introduce some system property to control that.
Honza S. is working on it. Reassign back to fine-tune on iOS.
I have prepared the workaround: http://hg.netbeans.org/web-main/rev/fe119965b1e2 There is NetBeans.clientRectsBug flag that determines when the workaround should be used. It is set to false by now. Please, try to set it to true and check whether this workaround helps. If so, then try to fine-tune its value such that the workaround is used for iOS 7 only.
Changeset: 4d290287853c Author: Jan Becicka <jbecicka@netbeans.org> Date: 2013-09-30 14:26 Message: Now works correctly on both iOS 6 and iOS 7
Thanks for the patch.
Thank you, I've tried it on iPad with iOS7 and works OK now. The flag is set to "null" in iOS6 so it is evaluated as false thus nothing should change. Verified in web-main Product Version: NetBeans IDE Dev (Build web-main-11702-on-20130930) Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b14 System: Mac OS X version 10.8.5 running on x86_64; UTF-8; en_US (nb)
Please integrate all fixes into releases/release74 branch TODAY (10/1) by 10pm CEST, we are going to build final 7.4 build during the night. Thanks in advance.
Fixed in release74
verified in 7.4