Closed Bug 1217559 Opened 9 years ago Closed 9 years ago

Can't reload the toolbox on windows 10

Categories

(DevTools :: General, defect)

defect
Not set
normal

Tracking

(firefox44 fixed)

RESOLVED FIXED
Firefox 44
Tracking Status
firefox44 --- fixed

People

(Reporter: pbro, Assigned: ochameau)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files, 1 obsolete file)

This might totally be me doing something wrong because I have never tried this before, but I encountered some weird things when trying to reload the toolbox on Windows and thought I'd file a bug.

Please let me know if some of these things are problems on my side, or if we want to have separate bugs for each:

- `tools srcdir` only worked with this path for me: "C:/Users/Patrick/dev/fx-team"
Trying to use this failed: "C:\Users\Patrick\dev\fx-team" although that's the path you'd actually see in a windows command prompt.
It fails with:

C:\Users\Patrick\devx-team does not exist or is not a mozilla-central checkout.

- Once I execute `tools srcdir "C:/Users/Patrick/dev/fx-team"`, the toolbox closes and doesn't re-opens. I would expect the toolbox to just stay there until I enter `tools reload`.

- `tools reload` didn't seem to work. I made a simple change in markup-view.xhtml (adding some inline style so it would be easy to see if the changed worked), then entered `tools reload`: the toolbox closed and didn't re-open. And when I reopened it manually, my change wasn't there.
Update: I just tried ith markup-view.js and reloading did work for this file (but as I said, it'd be nice if the toolbox would re-open on its own).

- I then tried the keyboard shortcut, it's supposed to be accel+alt+r, but this didn't do anything for me. I made sure the toolbox had focus before.
CTRL+MAJ+R should reload and reopen the toolbox automagically.
I haven't tried modifying markup-view.xhtml, but toplevel tools xul/js files and it works fine on linux.
But it is very likely possible that something is wrong with windows file paths...
Also note that toolbox are often broken when reloading, I embedded some fixes in bug 1216979's patch.
(In reply to Alexandre Poirot [:ochameau] from comment #1)
> CTRL+MAJ+R should reload and reopen the toolbox automagically.
Hm, that seems to just reload the page for me on windows.
Sorry, I mispelled the shortcut, it is CTRL+ALT+R.
when using tools srcdir xxx, you can double check that it works correctly by looking at devtools.loader.srcdir pref. You have to reload the toolbox manually once to have the shortcut to work as it set the key listener on toolbox startup only, only if you have the pref set.
I checked on linux and modifying the markup-view.xhtml works fine.
I'll try to checkout a gecko clone on windows to figure this out,
but it takes soooo muuuch tiiiime. I wish we had a seperate devtools repo to avoid downloading 3GB of mozilla-central history :o
Ok. So what I see here is a URL mismatch.
We are opening chrome://devtools/content/markupview/markup-view.xhtml
whereas the magic trick tries to override chrome://markupview/content/markup-view.xhtml
(and correctly overrides it, I see the new content if I open this url)

I can't explain why it works on linux and not on windows.
It looks like the chrome.manifest generated by Loader.jsm is the same on both platforms.
But I think we have to update Loader.jsm's _writeManifest function according to the new URLs (not about the brand new resource one but the new chrome one related to the first file move to /devtools/)
Assignee: nobody → poirot.alex
Attached patch patch v1 (obsolete) — Splinter Review
Looks like it seems to work when working on a local build,
where symlinks are doing the trick...
Original jar content where still mapping to the jar.
The writeManifest method was generating new set of chrome URL
that wasn't overriding anything, but instead creating new URLs.
Hopefully the added test is going to cover this.

I verified with try build, and I got it to work on windows as expected with this patch.

I still need to ensure the test pass on all platforms.
Finding the source directory during tests isn't that obvious.
Last try attempt for writing a test for this.
I think we don't have any m-c checkout when running mochitests :x
Instead we just have a tarball with test files referenced in *.ini support-files section...
If that's the case, we can't test this for real, which is really unfortunate.
Attached patch patch v2Splinter Review
Ok, so there is no way to test this feature on our test slaves
as they don't checkout gecko while running tests :/
Attachment #8679632 - Flags: review?(jryans)
Attachment #8679139 - Attachment is obsolete: true
For posterity, in case we find a way to get access to a gecko checkout...
Comment on attachment 8679632 [details] [diff] [review]
patch v2

Review of attachment 8679632 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for fixing this!  The old version is definitely not right.
Attachment #8679632 - Flags: review?(jryans) → review+
https://hg.mozilla.org/integration/fx-team/rev/961e078286dc3977319c2717ed4d0f6b94ed6f3d
Bug 1217559 - Fix chrome overrides after new devtools files layout. r=jryans
https://hg.mozilla.org/mozilla-central/rev/961e078286dc
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: