Closed Bug 42313 Opened 24 years ago Closed 23 years ago

Unable to scroll with mousewheel over objects contained in IFRAMEs

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.5

People

(Reporter: bugzilla, Assigned: bryner)

References

(
URL
)

Details

(Keywords: topembed, Whiteboard: PDT+)

Attachments

(1 file)

patch
4.27 KB, patch
hyatt
: superreview+
Details | Diff | Splinter Review 
Build ID: 2000061208

With the MS IntelliMouse IntelliEye, for whatever reason, I'm unable to scroll 
the page when the mouse is over these three images along the right side of the 
page: "amazon.com", "Join our affiliate program. Earn Money!", and "Great Jobs 
Ahead. Click Here".  If you put the mouse above these images and begin to 
scroll down, page scrolling stops immediately when the mouse passes over these 
images (and same if you put the mouse below them and scroll upwards).  Kinda 
like what used to happen with <textarea>'s.

Any idea what's goin' on here?
Well, those three images are actually contained in IFRAMEs. But I'm mousewheel
challenged, so I'm not sure what the scrolling behaviour for embedded IFRAME
within a page is supposed to be (either in principle, or in existing browser
support (i.e. what does IE, which supports IFRAME do, for IE4 and IE5)
yep, you're right.  I hadn't really had much time to investigate this.  updating 
summary.
Summary: Unable to scroll with mousewheel over certain images on page → Unable to scroll with mousewheel over objects contained in IFRAMEs
Status: NEW → ASSIGNED
This is going to take some reworking of the code so that we traverse up to
parent presshells if we can't get a scrollableview in the current presshell.

However, there is another problem here that needs fixed ASAP - a crash when you
attempt to scroll over IFRAMEs.  I'm filing that as a separate bug and will mark
this dependent on it.
Depends on: 44444
Marking XP.

Nominating for beta3 - I have a rough fix for this now, and I think having the
page suddenly stop scrolling because an IFRAME came up under the pointer will
leave a pretty bad UI impression (and IFRAME's seem to be used regularly on
banner ads).
Keywords: nsbeta3
OS: Windows 98 → All
Hardware: PC → All
nsbeta3-
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
*** Bug 49045 has been marked as a duplicate of this bug. ***
*** Bug 55009 has been marked as a duplicate of this bug. ***
*** Bug 45736 has been marked as a duplicate of this bug. ***
mousewheel event targetting bugs -> mozilla 0.9
Target Milestone: Future → mozilla0.9
*** Bug 61191 has been marked as a duplicate of this bug. ***
a patch for this is attached to bug 57598
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Seems this one is back (at least on linux)
Mousewheel scrolling stops when over iframes - so does key-scrolling.
False alarm - it works. (Didn't for days though.)
*** Bug 83285 has been marked as a duplicate of this bug. ***
This is not working, as reported on bug 83285, and confirmed on win95 20010529.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Unsetting milestone. Good to fix for rtm/0.9.2
Keywords: nsbeta3 → mozilla0.9.2
Whiteboard: [nsbeta3-]
Target Milestone: mozilla0.9 → ---
*** Bug 84734 has been marked as a duplicate of this bug. ***
*** Bug 85699 has been marked as a duplicate of this bug. ***
See also bug 62431, Mousewheel should only scroll scrollable textareas.
*** Bug 83800 has been marked as a duplicate of this bug. ***
Status: REOPENED → ASSIGNED
a lot of dupes here should really go to bug 59211, which by the way has patch
pending review attached to it.
*** Bug 92536 has been marked as a duplicate of this bug. ***
I suspect the iframe and plugin issues are entirely different.
Don't they both involve handling child windows?
If iframes are not a separate child window - then I guess not.
However, if they are, I think it's the same issue of passing event messages to
and from child windows and processing them.
Marking mostfreq @ 10 dups.
Keywords: mostfreq
How about that: iframes (even if scrollable) are never scrolled by the
mousewheel, unless they have focus. I understand that this would be a problem,
if <iframe>s are used like <frame>s. But if there's some small (like the big
CNET ads), but scrollable iframe, I don't want the mouse scrolling of the page
stop over it.

Anyways, I would appreciate any of the suggested fixes.
*** Bug 95792 has been marked as a duplicate of this bug. ***
Should the "mozilla0.9.2" keyword be removed and/or replaced with another keyword?
I think the test URL, http://auctions.goto.com, changed because I don't see 
anything scrollable on it (after it finishes redirecting).  Can we get another 
URL?


Ok, here's a new url: http://www.weather.com/ (changed url field above as well).
Try scrolling while the mouse pointer is over the map.

Also, I removed "mozilla0.9.2" keyword since that was far in the past. Add more
recent keyword?
URL: http://auctions.goto.com → http://www.weather.com/
Keywords: mozilla0.9.2
Removing nsbranch (I don't think this will be going in on the 0.9.4 branch),
target for 0.9.5.
Keywords: nsbranch
Target Milestone: --- → mozilla0.9.5
Attached patch patch — — Splinter Review 

    
    

    
  
Ok, here's a brief description of the patch I just attached.  There are two main
fixes going on here:

- We now check the scroll position of the view before and after calling
ScrollBy[Lines|Pages] on it.  This allows us to check whether the view can
actually be scrolled without duplicating the logic in the scrolling view code. 
If the view can't be scrolled, we try to scroll the parent document (see below).

- The way we were finding a new target frame when passing up the event to a
parent document was wrong.  We don't need to mess around with the event
coordinates, now we just use FindContentForDocShell, which gives us the content
node in the parent document that corresponds to our docshell; and use its frame
as the event target.


    
    

    
  
looks good, r=saari

    
    

    
  
Comment on attachment 48387 [details] [diff] [review]
patch

sr=hyatt

        Attachment #48387 -
        Flags: superreview+

    
    

    
  
checked in.

Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 98963 has been marked as a duplicate of this bug. ***

    
    

    
  
can we get this on the 0.9.4 branch, please?

    
  
Keywords: nsbranch+, 
          
            topembed

    
    

    
  
check it in - PDT+.

What other bugs exists that affect mouse wheel support? What are some good ways
to test this?

Mdunn - Can you test this in the embedded application?
Whiteboard: PDT+

    
    

    
  
*** Bug 101375 has been marked as a duplicate of this bug. ***

    
    

    
  
I just checked the patch into the branch.

There's no component specifically for mousewheel bugs, but nearly all of them
are assigned to me, so that's your best bet for locating them.  This was the
only mousewheel fix checked into the trunk after 0.9.4 branched.


    
    

    
  
verified fixed on mac/linux/win32 with help from jag & bryner (who have the 
mousewheels that I don't).
Status: RESOLVED → VERIFIED

    
    

    
  
*** Bug 104214 has been marked as a duplicate of this bug. ***

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: