Hmm, it seems the platform explicitly blocks new URL() from parsing chrome:// URLs. :/ Any random scheme name works, so chrome must be banned for some reason. Anyway, we should make this work one way or another.
Created attachment 8572635 [details] [diff] [review] Don't let WebIDE break when trying to debug Chrome settings It turns out that chrome: URLs are parsed properly, but only those that are actually valid for Firefox (which chrome://settings is not). Therefore I just ignore these URLs, since I can't think of a way to debug them properly. I couldn't write a test for the same reason: using something like chrome://webide/content would work even without the patch and using chrome://settings would throw when trying to create the tab in Firefox.
Attachment #8572635 - Flags: review?(poirot.alex)
Assignee: nobody → past
Status: NEW → ASSIGNED
Comment on attachment 8572635 [details] [diff] [review] Don't let WebIDE break when trying to debug Chrome settings Review of attachment 8572635 [details] [diff] [review]: ----------------------------------------------------------------- Looks good to me, especially if these pages can't be debugged. Otherwise it would be better to fix that code to be able to display a meaningful label instead of skipping them. Also, may be valence should only expose the tabs it is able to debug?
Attachment #8572635 - Flags: review?(poirot.alex) → review+
Both good points. It turns out that these pages can indeed be debugged, it's just the tab list that can't handle them. I have a fix in Valence for this and I'll land this patch as a safeguard that WebIDE never breaks in the presence of an invalid URL.
Here is the change I mention above: https://github.com/campd/valence/pull/167 Can you review that too, please?
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
status-firefox39: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 39
You need to log in before you can comment on or make changes to this bug.