Closed Bug 89911 Opened 24 years ago Closed 24 years ago

x-remote support needs some cleanup

Categories

(Core Graveyard :: X-remote, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: blizzard, Assigned: blizzard)

References

Details

(Whiteboard: [xremote])

The X remote support that we have really needs cleanup. There are several problems. o We put the supporting property on not just toplevel windows but popup windows as well. I have to figure out a way to distinguish in between a window that's part of mozilla-the-browser and another window like a popup or dialog. We don't want to get requests on those kinds of windows. o We don't support the -id argument like the old netscape nav 4.x We need to add support to the command line handler to support -id so you can specifiy ids of windows. This is all client side and is pretty easy to do. o We put properties on windows when they shouldn't have them, like in embedding applications. We need to move the logic that sets up remote support up into the application so we can tell what kinds of windows they are. Not sure how to do this yet. o We don't share any code in between windows or linux The code that's in xpfe for native windows DDE contains much of the same code that's in my remote helper code. I'm pretty sure that we could componentize this code and share it. Also, this would help me build a -turbo mode equivalent for linux. I'll file bugs to get this work done. The last is why people are cc'ed.
Depends on: 81324
Depends on: 90580
Depends on: 62250
Whiteboard: [xremote]
Depends on: 98603
Fixed
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Component: Browser-General → X-remote
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.