1217559 - Can't reload the toolbox on windows 10

Status: RESOLVED FIXED

(DevTools :: General, defect)

Description

[Patrick Brosset <:pbro>]

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.

Comment 1

[Alexandre Poirot [:ochameau]]

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.

Comment 2

[Patrick Brosset <:pbro>]

(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.

Comment 3

[Alexandre Poirot [:ochameau]]

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.

Comment 4

[Alexandre Poirot [:ochameau]]

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

Comment 5

[Alexandre Poirot [:ochameau]]

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/)

Comment 6

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=ba7863e577bc

Comment 7

[Alexandre Poirot [:ochameau]]

Attachment: patch v1

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.

Comment 8

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=c07e6deddac2

Comment 9

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=0ea2ac8f7431

Comment 10

[Alexandre Poirot [:ochameau]]

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.

Comment 11

[Alexandre Poirot [:ochameau]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=137dbfec8704

Comment 12

[Alexandre Poirot [:ochameau]]

Attachment: patch v2

Ok, so there is no way to test this feature on our test slaves
as they don't checkout gecko while running tests :/

Comment 13

[Alexandre Poirot [:ochameau]]

Attachment: test devtools.loader.srcdir pref

For posterity, in case we find a way to get access to a gecko checkout...

Comment 14

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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.

Comment 15

[Alexandre Poirot [:ochameau]]

https://hg.mozilla.org/integration/fx-team/rev/961e078286dc3977319c2717ed4d0f6b94ed6f3d
Bug 1217559 - Fix chrome overrides after new devtools files layout. r=jryans

Comment 16

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/961e078286dc