Can't reload the toolbox on windows 10

RESOLVED FIXED in Firefox 44



Developer Tools
2 years ago
2 years ago


(Reporter: pbro, Assigned: ochameau)


(Blocks: 2 bugs)

Firefox 44
Dependency tree / graph

Firefox Tracking Flags

(firefox44 fixed)



(2 attachments, 1 obsolete attachment)



2 years ago
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

2 years ago
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

2 years ago
(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

2 years ago
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

2 years ago
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

2 years ago
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/)


2 years ago
Assignee: nobody → poirot.alex

Comment 7

2 years ago
Created attachment 8679139 [details] [diff] [review]
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 10

2 years ago
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 12

2 years ago
Created attachment 8679632 [details] [diff] [review]
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 :/
Attachment #8679632 - Flags: review?(jryans)


2 years ago
Attachment #8679139 - Attachment is obsolete: true

Comment 13

2 years ago
Created attachment 8679633 [details] [diff] [review]
test devtools.loader.srcdir pref

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+

Comment 15

2 years ago
Bug 1217559 - Fix chrome overrides after new devtools files layout. r=jryans

Comment 16

2 years ago
Last Resolved: 2 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
You need to log in before you can comment on or make changes to this bug.