Closed Bug 544454 Opened 15 years ago Closed 15 years ago

IDM download panel affected by a11y API changes

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mucinch, Unassigned)

Details

(Keywords: regression)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100204 Firefox/3.7a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100204 Firefox/3.7a1pre Bug 542702 - Remove unused variable childLength in nsXFormsAccessible::CacheSelectChildren (Changeset b8635ef804f7) breaks IDM Download Panel. It also interferes with flash video catching. Reproducible: Always Steps to Reproduce: 1.Click on any youtube or other flash video 2. 3. Actual Results: there is no download panel on the top right of the page
Version: unspecified → Trunk
Yes, this is a problem with IDM. Not only doesn't the download panel appear, but it also starts downloading videos from all over a web page automatically. Really unusable for video sites.
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.9.3a1pre) Gecko/20100204 Firefox/3.7a1pre > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.9.3a1pre) Gecko/20100204 Firefox/3.7a1pre > > Bug 542702 - Remove unused variable childLength in > nsXFormsAccessible::CacheSelectChildren (Changeset b8635ef804f7) breaks IDM > Download Panel. It also interferes with flash video catching. I haven't had a chance to look into this yet, but can you tell me how removing the unused variable is causing this problem?
(In reply to comment #2) > (In reply to comment #0) > > User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > > rv:1.9.3a1pre) Gecko/20100204 Firefox/3.7a1pre > > Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > > rv:1.9.3a1pre) Gecko/20100204 Firefox/3.7a1pre > > > > Bug 542702 - Remove unused variable childLength in > > nsXFormsAccessible::CacheSelectChildren (Changeset b8635ef804f7) breaks IDM > > Download Panel. It also interferes with flash video catching. > > I haven't had a chance to look into this yet, but can you tell me how removing > the unused variable is causing this problem? I am sorry, I cant help you technically. On testing with the hourlies, the build with the changeset b8635ef804f7 and those subsequent to it, started causing problems with IDM Download panels and video catching (videos started downloading automatically overriding User's input). Maybe I am mistaken, if so sorry for the trouble.
No worries. If someone else has time to confirm the regression window precisely that would help a lot...
Hey David, here is the best I could do. IDM works fine with this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100201 Firefox/3.6 ID:20100201043011 Doesn't work with this one: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100202 Firefox/3.6 ID:20100202053418 So the problem happened between the nightly builds of 02/01 and 02/02. Don't know how to find the hourlies if that's even possible.
(In reply to comment #5) > Hey David, here is the best I could do. > > IDM works fine with this build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.9.3a1pre) Gecko/20100201 Firefox/3.6 ID:20100201043011 > > Doesn't work with this one: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; > rv:1.9.3a1pre) Gecko/20100202 Firefox/3.6 ID:20100202053418 > > So the problem happened between the nightly builds of 02/01 and 02/02. Don't > know how to find the hourlies if that's even possible. http://hourly-archive.localgho.st/hourly-archive2/ Use this link to test the hourlies.
(In reply to comment #5) > Hey David, here is the best I could do. Thanks! Testing the hourly would help too. Also, once you find a range you can do about:buildconfig in the awesomebar and report the Build id changeset (the link). You could do this with the dailies as well if you have time. Much appreciated.
OK David, I found it. This hourly build works: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100201 Firefox/3.6 ID:20100201174142 changeset: 37806:5c6c40887584 This next hourly build does not: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100201 Firefox/3.6 ID:20100201204228 changeset - 37809:b8635ef804f7 Thanks guys for the info on the hourlies and the tip about changeset.
Great, thanks. So here is the pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c6c40887584&tochange=b8635ef804f7 b8635ef804f7 David Bolter — Bug 542702 - Remove unused variable childLength in nsXFormsAccessible::CacheSelectChildren. r=surkov fb6bebbcf7f3 David Bolter — Bug 542221 - DeCOMtaminate some usage of nsAccessibilityService. r=surkov 70da16e4c483 David Bolter — Bug 543033 - Remove unused getAccessibleInWindow (in nsIAccessibleRetrieval). r=surkov I wonder if IDM uses getAccessibleInWindow?
What is IDM? Is it http://www.internetdownloadmanager.com/? (In reply to comment #9) > I wonder if IDM uses getAccessibleInWindow? Good guess. We could get back this method. But I wonder why do they need a11y. Could we get them in contact?
Yes, Alexander, that is the correct program in question. Been using it for a long time and it is great.
David, could you get back this method and put try server build? I think if it's cause of a problem then we should expose the method and try to contact with IDM. It looks like the case when a11y provides very-very handy stuffs and extension authors use them instead a trying to find out non-a11y way.
Ok, IDM has Firefox extension and XPCOM component ("@idm/mozilla_cc"). An extension doesn't contain any a11y calls but they could be inside of XPCOM component. Since it's C++ component then they can use nsIAccessibilityService.
(In reply to comment #12) > I think if it's > cause of a problem then we should expose the method and try to contact with > IDM. Any way since nsIAccessiblilityService is changed actively last time then they need to rebuild their component for new Firefox version which might mean they don't use GetAccessibleInWindow actually.
Keywords: regression
Summary: Fix for Bug 542702 breaks IDM download panel → IDM download panel affected by a11y API changes
I reached out via there contact form.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Thank you for reporting this problem, David. IDM's "download panel" uses several alternative methods to find screen coordinates where to draw "download this video/audio" button. We will try to add a fix for this version of Firefox later today. Kind regards Charles Jones Software engineer Tonec Inc. 641 Lexington Avenue, 15th fl. New York, NY, 10022
Charles, thank you for looking at this. Could you think of a way to not use accessibility? Accessibility is developed for screen readers and other AT. It's heavy module and sighted Firefox users might get unnecessary performance problems when you use it. I believe you should be able to get the same information without accessibility. For example, you might find useful GetClientRects() method (http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/core/nsIDOMNSElement.idl#69) to get DOM element coordinates.
The problem is fixed with the latest version of IDM CC (6.9.3). Thanks guys for the speedy resolution of the problem.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
It's not fixed until the fix is on our side.
(In reply to comment #19) > It's not fixed until the fix is on our side. So, should I change the status back to NEW?
If you don't know where the problem was and you can't reproduce the problem any more then worskforme. If it wasn't our bug then invalid.
Ok, I am changing the status to WORKSFORME.
Resolution: FIXED → WORKSFORME
Hi, we use nsIDOMNSElement in a primary method, but some interfaces it uses have been changed as well. If the primary method fails, we use "accessibility". Once you change several interface IIDs again, and both methods fail to get coordinates, the button may stop working, and we will need to check/add new IIDs to get it work. Now you don't need to do anything on your side, the problem has been fixed in IDM CC 6.9.3. We have renewed the extension with new interfaces and placed it to sand box. Please assist to update the version on addons.mozilla.org if you can. kind regards, Charles Jones Tonec Inc.
If accessibility methods usage is a protection from nsIDOMNSElement changed uid then it doesn't make a lot of sense. You should check if DOM interfaces were changed if you want to support the users of nightly build Firefox (interfaces are changed for stable releases very rare). If nsIDOMNSElement doesn't work for you well then you should request needed features.
I agree with Alexander; while your fallback is clever, given the intended use of the a11y service the performance and other issues it can create, we strongly encourage you remove it. Charles, thanks for helping us resolve this issue so quickly after I had contacted you. I should note I didn't report this issue, and thanks go to mucinch for that.
We try to use "accessibility" only if DOM interfaces have been changed. We also use "accessibility" via interfaces (nsIAccessibleRetrieval in particular), and we check results on every step, and check interface pointers. Thus it will be no crashes or performance issues. When uid is changed the component doesn't get a pointer to the interface and nothing is done afterwards, just some functionality of the extension gets lost, but it doesn't influence the Firefox. If you changed DOM interfaces uids rarely, we would not need to add new uids to the extension frequently.
(In reply to comment #26) > We try to use "accessibility" only if DOM interfaces have been changed. We also > use "accessibility" via interfaces (nsIAccessibleRetrieval in particular), and > we check results on every step, and check interface pointers. Thus it will be > no crashes or performance issues. Firefox users will get performance problems once you enabled accessibility (when you obtained nsIAccessibleRetrieval service). It's very powerful module and therefore it's very heavy. It is unloaded until someone starts it. When you used it then we create accessible tree, fire events and do lot of things. And it doesn't matter if you do not call accessibility methods any more. Please do not use accessibility as a protection of changed DOM interfaces uid.
(In reply to comment #27) > (In reply to comment #26) > Firefox users will get performance problems once you enabled accessibility To expand on this point: the performance problems will come from our accessibility engine assuming all information throughout firefox, and the content it renders, needs to be delivered via accessibility. For example we will cache and update accessible objects based on DOM events.
You need to log in before you can comment on or make changes to this bug.