Closed
Bug 568647
Opened 14 years ago
Closed 12 years ago
Isolate Firefox-specific APIs and global usage into the Firefox Application Hooks
Categories
(DevTools :: General, defect)
Tracking
(blocking2.0 -)
RESOLVED
WONTFIX
Future
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: ddahl, Assigned: ddahl)
References
Details
Attachments
(1 file)
9.30 KB,
patch
|
Details | Diff | Splinter Review |
The console may be used with other Gecko-based applications, in which case we need to de-Firefox the core code and move all Fx-specific calls into the Firefox application hooks object.
Assignee | ||
Comment 1•14 years ago
|
||
De-prioritizing this for now as we really focus on FX 4 betas.
Severity: major → normal
Priority: -- → P3
This moves at least the FirefoxApplicationHooks bits into a separate file in browser/ (loaded via resource://app/); this way the host app just needs to provide a replacement of that file. Just a start since ddahl mentioned that lots of small patches would probably better than a giant thing at the end in this case (though I have no idea where he prefers to track patches - I'm open to that). Still todo: move all the tabbrowser stuff there too. I intend to let the HUDService just know that 1) there are toplevel chrome windows, 2) there are content (sub-)windows, and 3) there are IDs for the content windows that the app-specific bits will return and you can get the output that way. But that's still planning ;)
Attachment #455634 -
Flags: review?(ddahl)
Requesting blocking, err, something, since this is Firefox-specific code inappropriately leaking into toolkit/ and platform releases are tied to Firefox so there's no chance to fix this after Firefox goes out. Note that the attached patch is only the start; I need more feedback before continuing.
blocking2.0: --- → ?
Comment 4•14 years ago
|
||
Talked to ddahl, I think the better solution would be to move this code entirely into browser/ and let other apps copy and modify it as necessary. But it's not a blocker.
blocking2.0: ? → -
Comment 5•14 years ago
|
||
david created bug 579909 to discuss moving the console to browser.
Assignee | ||
Comment 6•14 years ago
|
||
Comment on attachment 455634 [details] [diff] [review] initial patch I really like the direction you are taking this, but in the near term we may end up moving all of this code in to browser anyway, nailing it all down before going gecko-agnostic. And this will allow us to keep Firefox-specific tests out of toolkit. I really appreciate your effort and I am bummed we will not be doing so sooner. Our release schedule is kind of accelerated.
Attachment #455634 -
Flags: review?(ddahl)
(In reply to comment #6) > I really appreciate your effort and I am bummed we will not be doing so > sooner. Our release schedule is kind of accelerated. Yeah, that's understandable - I never have enough time to do what I want either, including poking at this bug ;) I'll note however that's 5 weeks of (small chunks of) time I could have spent helping to make the console work better that was blocked, though :p Given that this is blocking2.0-, should bug 579909 then get blocking2.0? _One_ of the two should be blocking, I think...
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #7) > Given that this is blocking2.0-, should bug 579909 then get blocking2.0? _One_ > of the two should be blocking, I think... I cc'd shaver for "owner" weigh in. I think it will be blocking, of course the 3rd way is just moving the tests.
Comment 9•14 years ago
|
||
I don't think either *needs* to be a blocker. "console lives in toolkit/ but isn't app-agnostic" is obviously not what we want as an end-state, but I don't think it would necessarily prevent us from shipping.
Assignee | ||
Comment 10•14 years ago
|
||
(In reply to comment #9) > I don't think either *needs* to be a blocker. "console lives in toolkit/ but > isn't app-agnostic" is obviously not what we want as an end-state, but I don't > think it would necessarily prevent us from shipping. what do you think about just moving the tests into browser? Does it matter?
Comment 11•14 years ago
|
||
I don't really know the state of its usefulness to other apps. The tests should probably live with the code, wherever it is. If it's not useful to other apps in its current state, and we don't plan on fixing that (this bug?) soon, then we should fix bug 579909 I guess.
Comment 12•14 years ago
|
||
deprioritizing and adding a dependent bug where this work can take place.
Assignee | ||
Updated•13 years ago
|
Whiteboard: [console-close-me]
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Whiteboard: [console-close-me]
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•