Closed Bug 589089 Opened 14 years ago Closed 14 years ago

NetworkPanel: Show hint if response content-type can't be displayed

Categories

(DevTools :: General, defect)

defect
Not set
normal

Tracking

(blocking2.0 beta7+)

RESOLVED FIXED
Firefox 4.0b7
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: julian.viereck, Assigned: rcampbell)

References

Details

(Whiteboard: [kd4b6] [strings][patch-clean:20101012])

Attachments

(2 files, 13 obsolete files)

41.08 KB, patch
rcampbell
: review+
Details | Diff | Splinter Review
21.67 KB, patch
Details | Diff | Splinter Review
Attached patch Patch v1 (obsolete) — Splinter Review
      No description provided.
Attachment #467708 - Flags: feedback?(ddahl)
Whiteboard: [kd4b5]
Assignee: nobody → jviereck
Attached patch Patch v1.1 (obsolete) — Splinter Review
Improved patch: if the content type can't be read from the request/response, then try to get it from the requested URL file ending.
Attachment #467708 - Attachment is obsolete: true
Attachment #467935 - Flags: feedback?(ddahl)
Attachment #467708 - Flags: feedback?(ddahl)
Attached patch Patch v1.2 (obsolete) — Splinter Review
Don't check the "Accept" part of the request header. The content type can be false there. Just use the "Content-Type" value of the response header or the file ending to figure out the content type of the response body.
Attachment #467935 - Attachment is obsolete: true
Attachment #468258 - Flags: feedback?(ddahl)
Attachment #467935 - Flags: feedback?(ddahl)
Comment on attachment 468258 [details] [diff] [review]
Patch v1.2


>+  },
>+
>+  /**
>+   * Returns the file extension of a pased url.
>+   *
>+   * @param string aUrl
>+   *        URL to determ the file extension from.
>+   * @returns string or null
>+   *        The file extension as string or null if no URL is passed in.
>+   */
>+  getFileExtension: function NH_getFileExtension(aUrl)
>+  {
>+    if (!aUrl) {
>+      return null;
>+    }
>+
>+    // Remove query string from the URL if any.
>+    var queryString = aUrl.indexOf("?");
>+    if (queryString != -1) {
>+      aUrl = aUrl.substr(0, queryString);
>+    }

if you create a URI via Services.io.newURI(), you should have a property that gets this (and more) for you, which is the proper way of handling urls

>+
>+  mimeExtensionMap: {
>+      "txt": "text/plain",
>+      "html": "text/html",
>+      "htm": "text/html",
>+      "xhtml": "text/html",
>+      "xml": "text/xml",
>+      "css": "text/css",
>+      "js": "application/x-javascript",
>+      "jss": "application/x-javascript",
>+      "jpg": "image/jpg",
>+      "jpeg": "image/jpeg",
>+      "gif": "image/gif",
>+      "png": "image/png",
>+      "bmp": "image/bmp",
>+      "swf": "application/x-shockwave-flash",
>+      "flv": "video/x-flv"
>+  },
>+
I'm wondering id there is code for mapping mimetypes already in the mozilla tree. mxr mxr!

>+  // This is a list of all the mine category maps jviereck could find in the
>+  // firebug code base.
>+  mimeCategoryMap: {
>+    "text/plain": "txt",
> 


Please try to finds out if there is already a mapping for mimetypes that is usable in the moz code
Attachment #468258 - Flags: feedback?(ddahl) → feedback+
it might be nsIMimeTypeService or something
Comment on attachment 468258 [details] [diff] [review]
Patch v1.2

After talking to shawn it sounds like there is a service that will do this for: nsIMimeService

If it is crap, maybe not, but worth looking in to.
Attachment #468258 - Flags: feedback+ → feedback-
(In reply to comment #3)
> Comment on attachment 468258 [details] [diff] [review]
> Patch v1.2
> 
> 
> >+  },
> >+
> >+  /**
> >+   * Returns the file extension of a pased url.
> >+   *
> >+   * @param string aUrl
> >+   *        URL to determ the file extension from.
> >+   * @returns string or null
> >+   *        The file extension as string or null if no URL is passed in.
> >+   */
> >+  getFileExtension: function NH_getFileExtension(aUrl)
> >+  {
> >+    if (!aUrl) {
> >+      return null;
> >+    }
> >+
> >+    // Remove query string from the URL if any.
> >+    var queryString = aUrl.indexOf("?");
> >+    if (queryString != -1) {
> >+      aUrl = aUrl.substr(0, queryString);
> >+    }
> 
> if you create a URI via Services.io.newURI(), you should have a property that
> gets this (and more) for you, which is the proper way of handling urls

k.

> 
> >+
> >+  mimeExtensionMap: {
> >+      "txt": "text/plain",
> >+      "html": "text/html",
> >+      "htm": "text/html",
> >+      "xhtml": "text/html",
> >+      "xml": "text/xml",
> >+      "css": "text/css",
> >+      "js": "application/x-javascript",
> >+      "jss": "application/x-javascript",
> >+      "jpg": "image/jpg",
> >+      "jpeg": "image/jpeg",
> >+      "gif": "image/gif",
> >+      "png": "image/png",
> >+      "bmp": "image/bmp",
> >+      "swf": "application/x-shockwave-flash",
> >+      "flv": "video/x-flv"
> >+  },
> >+
> I'm wondering id there is code for mapping mimetypes already in the mozilla
> tree. mxr mxr!

mxr did a poor job, but google helped!: http://www.oxymoronical.com/experiments/xpcomref/applications/Firefox/3.5/interfaces/nsIMIMEService

There is a getTypeFromURI function, that should be what I'm looking for :)

> 
> >+  // This is a list of all the mine category maps jviereck could find in the
> >+  // firebug code base.
> >+  mimeCategoryMap: {
> >+    "text/plain": "txt",
> > 
> 
> 
> Please try to finds out if there is already a mapping for mimetypes that is
> usable in the moz code

I couldn't find a mapping of this kind. Can you think of an place where this might be used in a Mozilla project? This is an ugly long list, but if we can't find a solution for this I don't want to spend much time on this and get things going for beta5. This should be easy to exchange later if a better idea comes up.
(In reply to comment #3)
> if you create a URI via Services.io.newURI(), you should have a property that
> gets this (and more) for you, which is the proper way of handling urls

You probably want something like:
var uri = newURI(someSpec);
if (uri instanceof Ci.nsIURL)
  uri.query = "";
nsIMIMEService sounds like exactly what you want, why wasn't it suitable?
Attached patch Patch v2 (obsolete) — Splinter Review
This is a rebased patch, HTML -> XHTML + DTD + uses the nsIMIMEService service to get the content type from an extension.

I've tested this on www.google.de, inspecting the URL: 

http://www.google.de/extern_js/f/CgJkZRICZGUrMEU4ASwrMFo4AywrMA44ACwrMBc4BywrMCc4BCwrMDw4AywrMFE4AywrMAo4c0AdLCswFjgdLCswGTggLCswJTjKiAEsKzA1OAQsKzBAOBIsKzBBOAUsKzBOOAYsKzBUOAEsKzAYOAUsKzAmOA0sgAIXkAIY/ZaDznvXLkKA.js

I've added some Services.console.logStringMessage() that you can see in the patch (in the get _contentType() getter function). The output in the error console looks like this:

  FileExt: js
  FileType1: text/x-c++
  FileType2: text/x-c++

Is this a bug or a feature that the file extension "js" has the content type "text/x-c++"?
Attachment #468258 - Attachment is obsolete: true
Attachment #469422 - Flags: feedback?(ddahl)
This patch looks like it will be fairly straightforward, but it has a string so it should be a blocker for string freeze.
blocking2.0: --- → ?
Attached patch Patch v2.1 (obsolete) — Splinter Review
Improved patch. If the content-type starts with "text/" then assume it is text that we can display in the NetworkPanel body.
Attachment #469422 - Attachment is obsolete: true
Attachment #469711 - Flags: feedback?(ddahl)
Attachment #469422 - Flags: feedback?(ddahl)
Comment on attachment 469711 [details] [diff] [review]
Patch v2.1


>  _displayResponseBodyUnkownType: function NP_displayResponseBodyUnkownType()
"Unknown"

> XPCOMUtils.defineLazyGetter(this, "NetUtil", function () {
>   var obj = {};
>   try {
>     Cu.import("resource://gre/modules/NetUtil.jsm", obj);
>   } catch (err) {
catch on newline

>     Cu.reportError(err);
>   }
>   return obj.NetUtil;
you should return obj.NetUtil after the import statement


>+  mimeCategoryMap: {
so this does not exist anywhere else in the tree? I guess that is why FB has one too, huh?

>+    // Try to get the content type form the request file extension.
>+    let uri = Services.io.newURI(this.httpActivity.url, null, null);
>+    if (uri instanceof Ci.nsIURL) {
>+      let url = uri.QueryInterface(Ci.nsIURL);
>+      if (url.fileExtension) {
>+        Services.console.logStringMessage("FileExt: " + url.fileExtension);
>+        Services.console.logStringMessage("FileType1: " + mimeService.getTypeFromExtension(url.fileExtension));
>+        Services.console.logStringMessage("FileType2: " + mimeService.getTypeFromURI(uri));
Do these need to have strings?---------------^

>+  <div id="responseBodyUnkownType" style="display:none">
"unknown", not unkown - make sure you scour the file:)

>+    <h1>
>+      &networkPanel.responseBodyUnkownType;
>+      <span id="responseBodyUnkownTypeInfo" class="info">&Delta;</span>
>+    </h1>
>+    <div class="property-header" id="responseBodyUnkownTypeContenet"></div>
responseBodyUnkownTypeContenet should be responseBodyUnkownTypeContent

>+    checkNodeContent(networkPanel, "responseBodyCachedContenet", "<!DOCTYPE HTML>");
>+    checkNodeContent(networkPanel, "responseBodyCachedContenet", "</html>");
Check spelling here "Content" is correct

> // test property provider
>diff --git a/toolkit/locales/en-US/chrome/global/headsUpDisplay.properties b/toolkit/locales/en-US/chrome/global/headsUpDisplay.properties
>--- a/toolkit/locales/en-US/chrome/global/headsUpDisplay.properties
>+++ b/toolkit/locales/en-US/chrome/global/headsUpDisplay.properties
>@@ -94,8 +94,19 @@ NetworkPanel.durationMS=%Sms
> # This string is used to show the duration between the response header and the
> # response body event. It also shows the size of the received or cached image.
> #
> # The first %S is replace by the width of the inspected image.
> # The second %S is replaced by the height of the inspected image.
> # The third %S is replaced by the duration between the response header and the
> # response body event.
> NetworkPanel.imageSizeDeltaDurationMS=%Sx%Spx, Î%Sms
What is this unicode char? -----------------------^

>+<!ENTITY networkPanel.responseBodyUnkownType      "Content Type Unkown">
Unknown

I thought you also spelled "from" like "form" somewhere in this patch.

here:     // Try to get the content type form the request file extension.

f+ with changes and an interdiff from the previous patch for me to peek at real quick
Attachment #469711 - Flags: feedback?(ddahl) → feedback+
Attached patch Patch v2.2 (obsolete) — Splinter Review
Improved based on latest comments.
Attachment #469711 - Attachment is obsolete: true
Attachment #469728 - Flags: review?(sdwilsh)
Attached patch Patch v2.3 (obsolete) — Splinter Review
Rebased version.
Attachment #469728 - Attachment is obsolete: true
Attachment #469888 - Flags: review?(sdwilsh)
Attachment #469728 - Flags: review?(sdwilsh)
Comment on attachment 469888 [details] [diff] [review]
Patch v2.3

>+  // This is a list of all the mine category maps jviereck could find in the
>+  // firebug code base.
>+  mimeCategoryMap: {
>+    "text/plain": "txt",
[snip]
oy
>+    let uri = Services.io.newURI(this.httpActivity.url, null, null);
NetUtil.newURI(this.httpActivity.url)

>+    if (uri instanceof Ci.nsIURL) {
>+      let url = uri.QueryInterface(Ci.nsIURL);
no need for QI - instanceof does this for you automagically


>+<!ENTITY networkPanel.responseBodyUnknownType     "Content Type Unknown">
Might be better to use "Unknown Content Type".  Talk to UX?

r=sdwilsh
Attachment #469888 - Flags: review?(sdwilsh) → review+
> >+<!ENTITY networkPanel.responseBodyUnknownType     "Content Type Unknown">
> Might be better to use "Unknown Content Type".  Talk to UX?

Unknown Content Type is better for skimming, yes.
Attached patch [backed-out] Patch v2.4 (obsolete) — Splinter Review
Rebased patch + includes latest feedback from Shawn + Limi.
Attachment #469888 - Attachment is obsolete: true
This patch is ready for check-in but  it needs approval or blocking status.
Attachment #470113 - Flags: approval2.0?
To be clear on why this is a blocker: it adds a string (the "unknown content type" hint)
Whiteboard: [kd4b5] → [kd4b6]
Whiteboard: [kd4b6] → [kd4b6] [strings]
"needs a string" is not sufficient justification for something being a blocker :)

This looks like perhaps something we'd approve but not block on, but it's not very clear to me what exactly this patch is doing, just from readying the bug. It would help if every bug with a blocking request had a clear description of the work, an explanation of why the feature is important, its scope/impact, etc. You guys have all the context in your heads, but for someone like me who is less directly involved in the dev-tools work it's really hard to try and make blocking calls without that extra info.
blocking2.0: ? → beta6+
Keywords: checkin-needed
Comment on attachment 470113 [details] [diff] [review]
[backed-out] Patch v2.4

http://hg.mozilla.org/mozilla-central/rev/6505b9f8aad0
Attachment #470113 - Attachment description: Patch v2.4 → [checked-in] Patch v2.4
Status: NEW → RESOLVED
Closed: 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment on attachment 470113 [details] [diff] [review]
[backed-out] Patch v2.4

backed out in:
http://hg.mozilla.org/mozilla-central/rev/3105d6159ffa
Attachment #470113 - Attachment description: [checked-in] Patch v2.4 → [backed-out] Patch v2.4
FWIW, it'd be great if tests pass for a non-en-US builds, I don't think this one does?
(In reply to comment #24)
> FWIW, it'd be great if tests pass for a non-en-US builds, I don't think this
> one does?

Do you have the error output?
No, I just looked at the patch and there are two callsites in the test that do 
checkNodeContent(networkPanel, "responseBodyUnknownTypeContent", "Unable to display responses of type \"application/x-shockwave-flash\"");
which looks very much like it's hard-coding the string in en-US.
Done a try run with some more debug information. Calling

  nsIMIMEService.getTypeFromExtension("swf")

Causes an error on MacOsX64:

caught: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIMIMEService.getTypeFromExtension]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: resource://gre/modules/HUDService.jsm :: anonymous :: line 755"  data: no]

This doesn't seem to appear on other platforms (the OSX32 bit version works fine). Can this be a bug in nsIMIMEService.getTypeFromExtension that only happens on OSX64?
(In reply to comment #26)
> No, I just looked at the patch and there are two callsites in the test that do 
> checkNodeContent(networkPanel, "responseBodyUnknownTypeContent", "Unable to
> display responses of type \"application/x-shockwave-flash\"");
> which looks very much like it's hard-coding the string in en-US.

That's right - they are hard coded at some places. Sorry, I was not aware the tests are run with non en-US localization. There might be other places in the WebConsole unit tests that fail.
Assignee: julian.viereck → pwalton
Severity: normal → blocker
Reprioritizing bugs. You can filter the mail on the word TEABAGS.
Severity: blocker → normal
Blocks: devtools4b7
(In reply to comment #27)
> Done a try run with some more debug information. Calling
> 
>   nsIMIMEService.getTypeFromExtension("swf")
> 
> Causes an error on MacOsX64:
> 
> caught: [Exception... "Component returned failure code: 0x80040111
> (NS_ERROR_NOT_AVAILABLE) [nsIMIMEService.getTypeFromExtension]"  nsresult:
> "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame ::
> resource://gre/modules/HUDService.jsm :: anonymous :: line 755"  data: no]
> 
> This doesn't seem to appear on other platforms (the OSX32 bit version works
> fine). Can this be a bug in nsIMIMEService.getTypeFromExtension that only
> happens on OSX64?

I'm wondering if this is because there is no flash installed on OS X 64?

A try/catch should clear that. Stealing this away from Patrick...
Assignee: pwalton → rcampbell
Attached patch NetPanel show hint (v2.5) (obsolete) — Splinter Review
Updated patch with a try/catch block around nsIMIMEService.getTypeFromExtension(). Retrieved formatted strings for unittests so they should pass if localized.
Attachment #470113 - Attachment is obsolete: true
Attachment #473072 - Flags: review?(sdwilsh)
Comment on attachment 473072 [details] [diff] [review]
NetPanel show hint (v2.5)

>+    // Try to get the content type from the request file extension.
>+    let uri = NetUtil.newURI(this.httpActivity.url, null, null);
don't pass in the nulls - they aren't needed.

>+    let mimeType = null;
>+    if (uri instanceof Ci.nsIURL) {
>+      if (uri.fileExtension) {
merge these together so you don't have to indent so much:
if (uri instanceof Ci.nsIURL && uri.fileExtension) {

>+        try {
>+          mimeType = mimeService.getTypeFromExtension(uri.fileExtension);
>+        } catch(e) {
nit: bracing style is inconsistent with the rest of the file here (think you want catch on a new line)

>+          Cu.reportError(e.message);
I think you actually want to reportError(e).  Also please add a comment indicating why we catch this.

r=sdwilsh
Attachment #473072 - Flags: review?(sdwilsh) → review+
(review carried forward from previous)

Fixed with review nits addressed.
Attachment #473072 - Attachment is obsolete: true
Attachment #473191 - Flags: review+
Keywords: checkin-needed
ps, make sure this is tagged from Julian Viereck <jviereck@mozilla.com>. His patch.
(In reply to comment #34)
> ps, make sure this is tagged from Julian Viereck <jviereck@mozilla.com>. His
> patch.
This could easily be fixed by doing what http://blog.bonardo.net/2010/06/22/so-youre-about-to-use-checkin-needed asks for.
test failure on linux:(

JavaScript error: chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_HUDServiceTestsAll.js, line 239: Could not get the error message after page reload
TEST-INFO | chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_HUDServiceTestsAll.js | Console message: [JavaScript Error: "Could not get the error message after page reload" {file: "chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_HUDServiceTestsAll.js" line: 239}]
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_HUDServiceTestsAll.js | Test timed out

2nd run:

INFO | runtests.py | Running tests: end.
mochitest-browser-chrome failed:
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/components/console/hudservice/tests/browser/browser_HUDServiceTestsAll.js | input node is focused - Got , expected true
make: *** [mochitest-browser-chrome] Error 1

3rd run:

nsTraceRefcntImpl::DumpStatistics: 882 entries
TEST-PASS | automationutils.processLeakLog() | no leaks detected!

INFO | runtests.py | Running tests: end.
mochitest-browser-chrome passed

ARRGGHH. linux madness. Also this is my slower machine.

I think I will be checking this in anyway first thing california time.
http://hg.mozilla.org/mozilla-central/rev/5aaec9fb8993
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
I believe this was backed out as well.

http://hg.mozilla.org/mozilla-central/rev/99b5dc548631
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [kd4b6] [strings] → [kd4b6] [strings][check patch for bitrot before checking in]
What action needs to be done here? Can we defer to b8?
Looking at the parent of 99b5 in that push, http://hg.mozilla.org/mozilla-central/rev/3d53f19c5a13, the strings got backed out, too.
This patch was not the cause of the original backout. robcee is rebasing (has rebased?) the patch and is going to run a try build to make sure it still applies cleanly. That should be all that's required to reland this.
(In reply to comment #39)
> What action needs to be done here? Can we defer to b8?

we need to fix this up and try to reland it.

I'm pushing it through try now (it's been rebased).

There is one sad little string in this patch:
+<!ENTITY networkPanel.responseBodyUnknownType     "Unknown Content Type">
Comment on attachment 473191 [details] [diff] [review]
[backed-out] NetPanel show hint (v2.6)

http://hg.mozilla.org/mozilla-central/rev/c42cebfbcdf7
Attachment #473191 - Attachment description: NetPanel show hint (v2.6) → [checked-in] NetPanel show hint (v2.6)
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
Whiteboard: [kd4b6] [strings][check patch for bitrot before checking in] → [kd4b6] [strings]
Comment on attachment 473191 [details] [diff] [review]
[backed-out] NetPanel show hint (v2.6)

http://hg.mozilla.org/mozilla-central/rev/23fd6f6fefac
Attachment #473191 - Attachment description: [checked-in] NetPanel show hint (v2.6) → [backed-out] NetPanel show hint (v2.6)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
had to back this out due a test failure.

Patrick believes the test fix in bug 594145 will clear this up. I'm going to push the two to try and see what happens.
Attached patch NetPanel show hunt, split tests (obsolete) — Splinter Review
split out netpanel tests. Running through try.
Attachment #473191 - Attachment is obsolete: true
Attachment #480947 - Flags: review?(gavin.sharp)
Attached patch NetPanel show hint, split tests (obsolete) — Splinter Review
showing HINT, this time with 100% more tests!
Attachment #480947 - Attachment is obsolete: true
Attachment #480955 - Flags: review?(gavin.sharp)
Attachment #480947 - Flags: review?(gavin.sharp)
Attachment #480955 - Flags: review?(gavin.sharp)
Not sure if review is going to be required here or not. I've split and rewritten much of the unittest structure.

It passed on try, though I did see some sessionstore timeouts and one webconsole-netpanel (this test) time out on one machine. I'm going to retry to see if it was random or not. Hope to have results for noon.
Attachment #480955 - Attachment is obsolete: true
I'm still seeing some timeouts and assorted errors on try server. I have a couple of other things to test out, but this is getting rather painful.

I *think* most of the timeouts are in the TEST_ENCODING_ISO_8859_1 portion of the test.
Please note that we have now created a branch for beta 7 work. In addition to landing your fix on mozilla-central default, please also land it on mozilla-central GECKO20b7pre_20101006_RELBRANCH

(note: when landing on mozilla-central default, you will be given priority in the landing queue at https://wiki.mozilla.org/LandingQueue )
Latest version of the test code. Passes on everything with Flash installed. On machines without it, it's still causing an error to appear. I think I've got a check around the particular test and am running one more pass through try, but if this still fails, I think we'll have to comment out the test.
Attachment #481196 - Attachment is obsolete: true
Comment on attachment 482130 [details] [diff] [review]
[checked-in] NetPanel show hint (v2.6) 4

carrying review forward (from sdwilsh)
Attachment #482130 - Flags: review+
Any word on how the try build went?
Are there bugs on the problems with some machines not having Flash installed properly? All those machines should be identical, so if they're not we should get it fixed ASAP.
(In reply to comment #53)
> Any word on how the try build went?

Same failures as before.

(In reply to comment #54)
> Are there bugs on the problems with some machines not having Flash installed
> properly? All those machines should be identical, so if they're not we should
> get it fixed ASAP.

I'll file these today. Seems to be on Snowleopard opt and debug, win7 opt and win32 debug at a minimum.
Blocks: 603620
filed bug 603617 to get the machines' flash installs verified.
Latest test run showed all green except for a spurious session restore bug on snowleopard and a busted build on windows stemming from a timed-out hg pull.

I think this is ready to go with the final test commented out.

Attaching the current patch for mozilla central. After sending this. The existing patch plus the comments around the final test should apply against beta 7 branch.
ready for landing against mozilla-central
Keywords: checkin-needed
Whiteboard: [kd4b6] [strings] → [kd4b6] [strings][patch-clean:20101012]
Comment on attachment 482130 [details] [diff] [review]
[checked-in] NetPanel show hint (v2.6) 4

http://hg.mozilla.org/mozilla-central/rev/82b714389d8e
GECKO20b7pre_20101006_RELBRANCH
Attachment #482130 - Attachment description: NetPanel show hint (v2.6) 4 → [checked-in] NetPanel show hint (v2.6) 4
Comment on attachment 482629 [details] [diff] [review]
[checked-in] NetPanel show hint (v2.6) 5 - rebased 20101012

http://hg.mozilla.org/mozilla-central/rev/0582d89db930
Attachment #482629 - Attachment description: NetPanel show hint (v2.6) 5 - rebased 20101012 → [checked-in] NetPanel show hint (v2.6) 5 - rebased 20101012
Keywords: checkin-needed
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → FIXED
This appears to have increased the test_toolbar.xul failure rate dramatically on OS X (bug 578589). The last failure before that was in August.
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: