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)
DevTools
General
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 |
No description provided.
Attachment #467708 -
Flags: feedback?(ddahl)
Updated•14 years ago
|
Whiteboard: [kd4b5]
Updated•14 years ago
|
Assignee: nobody → jviereck
Reporter | ||
Comment 1•14 years ago
|
||
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)
Reporter | ||
Comment 2•14 years ago
|
||
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 3•14 years ago
|
||
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+
Comment 4•14 years ago
|
||
it might be nsIMimeTypeService or something
Comment 5•14 years ago
|
||
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-
Reporter | ||
Comment 6•14 years ago
|
||
(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.
Comment 7•14 years ago
|
||
(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 = "";
Comment 8•14 years ago
|
||
nsIMIMEService sounds like exactly what you want, why wasn't it suitable?
Reporter | ||
Comment 9•14 years ago
|
||
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)
Comment 10•14 years ago
|
||
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: --- → ?
Reporter | ||
Comment 11•14 years ago
|
||
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 12•14 years ago
|
||
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">Δ</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+
Reporter | ||
Comment 13•14 years ago
|
||
Improved based on latest comments.
Attachment #469711 -
Attachment is obsolete: true
Attachment #469728 -
Flags: review?(sdwilsh)
Reporter | ||
Comment 14•14 years ago
|
||
Rebased version.
Attachment #469728 -
Attachment is obsolete: true
Attachment #469888 -
Flags: review?(sdwilsh)
Attachment #469728 -
Flags: review?(sdwilsh)
Comment 15•14 years ago
|
||
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+
Comment 16•14 years ago
|
||
> >+<!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.
Reporter | ||
Comment 17•14 years ago
|
||
Rebased patch + includes latest feedback from Shawn + Limi.
Attachment #469888 -
Attachment is obsolete: true
Reporter | ||
Comment 18•14 years ago
|
||
This patch is ready for check-in but it needs approval or blocking status.
Updated•14 years ago
|
Attachment #470113 -
Flags: approval2.0?
Comment 19•14 years ago
|
||
To be clear on why this is a blocker: it adds a string (the "unknown content type" hint)
Updated•14 years ago
|
Whiteboard: [kd4b5] → [kd4b6]
Updated•14 years ago
|
Whiteboard: [kd4b6] → [kd4b6] [strings]
Comment 20•14 years ago
|
||
"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.
Updated•14 years ago
|
blocking2.0: ? → beta6+
Reporter | ||
Updated•14 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 21•14 years ago
|
||
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
Assignee | ||
Updated•14 years ago
|
Assignee | ||
Updated•14 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 22•14 years ago
|
||
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
Assignee | ||
Comment 23•14 years ago
|
||
see: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283281747.1283283872.25722.gz&fulltext=1 for details
Updated•14 years ago
|
Attachment #470113 -
Flags: approval2.0?
Comment 24•14 years ago
|
||
FWIW, it'd be great if tests pass for a non-en-US builds, I don't think this one does?
Comment 25•14 years ago
|
||
(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?
Comment 26•14 years ago
|
||
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.
Reporter | ||
Comment 27•14 years ago
|
||
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?
Reporter | ||
Comment 28•14 years ago
|
||
(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.
Updated•14 years ago
|
Assignee: julian.viereck → pwalton
Updated•14 years ago
|
Severity: normal → blocker
Comment 29•14 years ago
|
||
Reprioritizing bugs. You can filter the mail on the word TEABAGS.
Severity: blocker → normal
Updated•14 years ago
|
Blocks: devtools4b7
Assignee | ||
Comment 30•14 years ago
|
||
(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 | ||
Updated•14 years ago
|
Assignee: pwalton → rcampbell
Assignee | ||
Comment 31•14 years ago
|
||
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 32•14 years ago
|
||
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+
Assignee | ||
Comment 33•14 years ago
|
||
(review carried forward from previous) Fixed with review nits addressed.
Attachment #473072 -
Attachment is obsolete: true
Attachment #473191 -
Flags: review+
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 34•14 years ago
|
||
ps, make sure this is tagged from Julian Viereck <jviereck@mozilla.com>. His patch.
Comment 35•14 years ago
|
||
(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.
Comment 36•14 years ago
|
||
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.
Comment 37•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/5aaec9fb8993
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 4.0b6
Assignee | ||
Comment 38•14 years ago
|
||
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]
Comment 39•14 years ago
|
||
What action needs to be done here? Can we defer to b8?
Comment 40•14 years ago
|
||
Looking at the parent of 99b5 in that push, http://hg.mozilla.org/mozilla-central/rev/3d53f19c5a13, the strings got backed out, too.
Comment 41•14 years ago
|
||
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.
Assignee | ||
Comment 42•14 years ago
|
||
(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">
Assignee | ||
Comment 43•14 years ago
|
||
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)
Assignee | ||
Updated•14 years ago
|
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Whiteboard: [kd4b6] [strings][check patch for bitrot before checking in] → [kd4b6] [strings]
Assignee | ||
Comment 44•14 years ago
|
||
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)
Assignee | ||
Updated•14 years ago
|
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 45•14 years ago
|
||
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.
Assignee | ||
Comment 46•14 years ago
|
||
split out netpanel tests. Running through try.
Attachment #473191 -
Attachment is obsolete: true
Attachment #480947 -
Flags: review?(gavin.sharp)
Assignee | ||
Comment 47•14 years ago
|
||
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)
Updated•14 years ago
|
Attachment #480955 -
Flags: review?(gavin.sharp)
Assignee | ||
Comment 48•14 years ago
|
||
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
Assignee | ||
Comment 49•14 years ago
|
||
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.
Comment 50•14 years ago
|
||
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 )
Assignee | ||
Comment 51•14 years ago
|
||
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
Assignee | ||
Comment 52•14 years ago
|
||
Comment on attachment 482130 [details] [diff] [review] [checked-in] NetPanel show hint (v2.6) 4 carrying review forward (from sdwilsh)
Attachment #482130 -
Flags: review+
Comment 53•14 years ago
|
||
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.
Assignee | ||
Comment 55•14 years ago
|
||
(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.
Assignee | ||
Comment 56•14 years ago
|
||
filed bug 603617 to get the machines' flash installs verified.
Assignee | ||
Comment 57•14 years ago
|
||
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.
Assignee | ||
Comment 58•14 years ago
|
||
ready for landing against mozilla-central
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Whiteboard: [kd4b6] [strings] → [kd4b6] [strings][patch-clean:20101012]
Assignee | ||
Comment 59•14 years ago
|
||
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
Assignee | ||
Comment 60•14 years ago
|
||
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
Assignee | ||
Updated•14 years ago
|
Keywords: checkin-needed
Assignee | ||
Updated•14 years ago
|
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Comment 61•14 years ago
|
||
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.
Updated•6 years ago
|
Product: Firefox → DevTools
You need to log in
before you can comment on or make changes to this bug.
Description
•