Closed
Bug 1081891
Opened 10 years ago
Closed 9 years ago
[e10s] Calling webNavigation.loadURI with url that trigger unknownContentType.xul dialog change the tab title to its address
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
People
(Reporter: tabmix.onemen, Assigned: mossop)
References
Details
Attachments
(1 file, 1 obsolete file)
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0 Build ID: 20141012030203 Steps to reproduce: 1. set browser.tabs.remote.autostart to true and restart Firefox 2. open tab (for example https://bugzilla.mozilla.org/) 3 open the console browser and enter in the command line loadURI("http://tmp.garyr.net/forum/download/file.php?id=1131") the address can be any address that trigger unknownContentType dialog Actual results: 1. Open text file dialog (unknownContentType.xul) open but the tab title change to its address https://bugzilla.mozilla.org/ Expected results: 1. the tab title should not change RemoteWebNavigation.loadURI set browser._contentTitle = "", but when unknownContentType DOMTitleChanged never happen, eventually onStateChange call tabbrowser.setTabTitle and since browser._contentTitle is empty setTabTitle return the address as a title
Reporter | ||
Updated•10 years ago
|
tracking-e10s:
--- → ?
Component: Untriaged → Tabbed Browser
OS: Windows 7 → All
Hardware: x86_64 → All
Summary: Calling webNavigation.loadURI with url that trigger unknownContentType.xul dialog change the tab title to its address → [e10s] Calling webNavigation.loadURI with url that trigger unknownContentType.xul dialog change the tab title to its address
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
Flags: firefox-backlog+
Assignee | ||
Updated•9 years ago
|
Points: --- → 5
Flags: qe-verify+
Updated•9 years ago
|
Assignee: jmathies → dtownsend
Status: NEW → ASSIGNED
Iteration: --- → 38.3 - 23 Feb
Assignee | ||
Comment 1•9 years ago
|
||
/r/4007 - Bug 1081891: Only reset the browser title when we start to switch to a new document location. Pull down this commit: hg pull review -r 1a409e35a48bdcc4f021674dbfae8d10dac71489
Attachment #8566164 -
Flags: review?(mconley)
Comment 2•9 years ago
|
||
Comment on attachment 8566164 [details] MozReview Request: bz://1081891/Mossop https://reviewboard.mozilla.org/r/4005/#review3243 Looks good - and bonus karma for the test. ::: browser/base/content/test/general/browser_unknownContentType_title.js (Diff revision 1) > +function waitForNewWindow() { It kills me that we have to write this kind of stuff all of the time. Luckily, I think it's all getting tossed together with the stuff smacleod is working on.
Attachment #8566164 -
Flags: review?(mconley) → review+
Assignee | ||
Comment 3•9 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/0bb440fbcbfe
Comment 4•9 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/0bb440fbcbfe
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
status-firefox38:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 38
Updated•9 years ago
|
QA Contact: cornel.ionce
Comment 5•9 years ago
|
||
Verified fixed using latest Aurora, build ID: 20150305004759 on Windows 7 64-bit, Mac OS X 10.9.5 and Ubuntu 12.04 32-bit. Followed the STR from the description and got the expected result.
Status: RESOLVED → VERIFIED
Updated•9 years ago
|
Assignee | ||
Comment 6•9 years ago
|
||
Attachment #8566164 -
Attachment is obsolete: true
Attachment #8618405 -
Flags: review+
Assignee | ||
Comment 7•9 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•