Closed
Bug 1319366
Opened 8 years ago
Closed 8 years ago
Clicking a link while presenting Google slides makes the navigation bar go black
Categories
(Firefox for Android Graveyard :: General, defect, P2)
Tracking
(platform-rel -, fennec53+, firefox50 ?, firefox51 ?, firefox52 ?, firefox53 affected, firefox54 affected)
RESOLVED
DUPLICATE
of bug 1341276
Firefox 54
People
(Reporter: ggp, Assigned: cnevinchen)
References
Details
(Whiteboard: [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSlides])
Attachments
(6 files)
Reproduced on a freshly-installed Nightly build, on a Nexus 5X phone running Android 7.0
Steps to reproduce:
1- Open any Google presentation that contains a link (example: https://docs.google.com/presentation/d/145gnd-wT8kbmA9YuXaCWYB9LYaKEFM7WmIkKHzKgP6Y/edit#slide=id.p)
2- Go into fullscreen/presentation mode
3- Click a link in the presentation
A new tab gets opened as expected, but its navigation bar is black and unusable (see attached screenshot). I can only recover from this by manually restarting the app.
Comment 1•8 years ago
|
||
Yep, I see this too on a Pixel XL using Nightly.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
status-firefox50:
--- → ?
status-firefox51:
--- → ?
status-firefox52:
--- → ?
status-firefox53:
--- → affected
Ever confirmed: true
OS: Unspecified → Android
Priority: -- → P2
Hardware: Unspecified → All
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → cnevinchen
Updated•8 years ago
|
tracking-fennec: ? → +
Assignee | ||
Updated•8 years ago
|
Assignee: cnevinchen → nobody
Assignee | ||
Comment 2•8 years ago
|
||
Hi Jim
I found that when the link is clicked, a new tab is opened cause I can receive the
"type":"Tab:Added" event, but the app stays in full screen mode. IMO it make more sense for GeckoView to leave full screen mode when opening a new link. How do you think?
Flags: needinfo?(nchen)
Assignee | ||
Updated•8 years ago
|
tracking-fennec: + → ?
Comment 3•8 years ago
|
||
Makes sense. More specifically, we should leave full screen mode when opening new tab / switching tabs.
Flags: needinfo?(nchen)
Updated•8 years ago
|
platform-rel: --- → ?
Whiteboard: [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSlides]
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → cnevinchen
tracking-fennec: ? → 53+
Assignee | ||
Comment 4•8 years ago
|
||
Hi Ray
Would you please help advise how can I change state if the full screen icon in videocontrols.xml?
I want to make the app leave full screen mode when a new tab is added.
I can do it in the Java world but I also want to change the status of the control wedget in JS
Flags: needinfo?(ralin)
Comment 5•8 years ago
|
||
Hi Nevin
I'm afraid that the controls doesn't belong to video controls(videocontrols.xml), video control shows up only when <video>/<audio> tags embedded in content. Could you provide me more details about your intention? Thanks.
Flags: needinfo?(ralin)
Assignee | ||
Comment 6•8 years ago
|
||
I've found this might be helpful for Google slide widghet. I'll test it tomorrow.
https://developer.mozilla.org/zh-TW/docs/Web/API/Document/exitFullscreen
Flags: needinfo?(cnevinchen)
Assignee | ||
Comment 7•8 years ago
|
||
Hi Jim
I can simple show the Chrome UI in Java side using
if (ActivityUtils.isFullScreen(this)){
LayerView layerView = mLayerView;
if (layerView != null) {
layerView.setFullScreenState(FullScreenState.NONE);
}
setFullScreen(false);
}
in
https://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#1814
But I'm not sure if it's better to do this in platform side?
Since platform will know when to leave full screen mode before adding a new tab.
Flags: needinfo?(s.kaspari)
Flags: needinfo?(nchen)
Comment 8•8 years ago
|
||
(In reply to Jim Chen [:jchen] [:darchons] from comment #3)
> Makes sense. More specifically, we should leave full screen mode when
> opening new tab / switching tabs.
We should already have code for this in browser.js.
This bug sounds a bit like it could be related to bug 1222798 - So I'll flag esawin additionally. :)
Flags: needinfo?(s.kaspari) → needinfo?(esawin)
See Also: → CVE-2017-5394
Comment 9•8 years ago
|
||
It's not directly related to bug 1222798, I couldn't find any code path for exiting fullscreen mode when adding a new tab.
I think the solution presented in comment 7 would be acceptable.
Flags: needinfo?(esawin)
Comment 10•8 years ago
|
||
(In reply to Eugen Sawin [:esawin] from comment #9)
> It's not directly related to bug 1222798, I couldn't find any code path for
> exiting fullscreen mode when adding a new tab.
If we open a new tab and do not switch to it (that's where the code is, right?) then I guess we do not need to leave fullscreen mode? Only when actually switching to a (new) tab?
Comment 11•8 years ago
|
||
(In reply to Sebastian Kaspari (:sebastian) from comment #10)
> (In reply to Eugen Sawin [:esawin] from comment #9)
> > It's not directly related to bug 1222798, I couldn't find any code path for
> > exiting fullscreen mode when adding a new tab.
>
> If we open a new tab and do not switch to it (that's where the code is,
> right?) then I guess we do not need to leave fullscreen mode? Only when
> actually switching to a (new) tab?
That's right, although I'm not sure we can easily support this use case with the current mechanics.
In this particular case (Google Docs presentation), opening a tab in background is not an option.
Assignee | ||
Comment 12•8 years ago
|
||
The fix in comment 7 got some problem. Only changing the Android UI not really make the browser leave full screen mode and will cause some strange behavior.
I end up handing it in JS side
if (ActivityUtils.isFullScreen(this)) {
GeckoAppShell.notifyObservers("FullScreen:Exit", null);
}
and in https://searchfox.org/mozilla-central/source/mobile/android/chrome/content/browser.js#1786
change
browser.contentDocument.exitFullscreen();
to
document.exitFullscreen();
But this still got some problem.
The new added tab will still show the content the last loaded tab. I'll have to switch to another tab and switch back to make it display.
I can't find the cause of this behavior since all JS events seems to be triggered correctly (tab:added->tab:selected .... even thumbnail is created correctly).
Would you please give me some hint? I'll try it next week. Thank you!
Flags: needinfo?(cnevinchen) → needinfo?(s.kaspari)
Comment 13•8 years ago
|
||
(In reply to Nevin Chen [:nechen] from comment #12)
> The new added tab will still show the content the last loaded tab. I'll have
> to switch to another tab and switch back to make it display.
> I can't find the cause of this behavior since all JS events seems to be
> triggered correctly (tab:added->tab:selected .... even thumbnail is created
> correctly).
Is it possible that you enter BrowserApp.selectTab while in fullscreen (and therefore set fullscreenTransitionTab) and then never receive a "fullscreenchange" event?
Comment 14•8 years ago
|
||
Looks like you are getting help from Eugen and Sebastian.
Flags: needinfo?(nchen)
Updated•8 years ago
|
Flags: needinfo?(s.kaspari)
Assignee | ||
Comment 15•8 years ago
|
||
If you go to the sample page that Julian has built for me https://nevin-lab.appspot.com/
You'll find that when clicking on the link and open a new tab, everything is working fine (using nightly)
Comment hidden (mozreview-request) |
Assignee | ||
Comment 17•8 years ago
|
||
Hi Eugen.
Please correct me if I'm wrong....
I can't find when BrowserApp.selectTab is called while adding a new tab... so it might not be the cause?
Hi Jim.
I still need your wisdom here.
When fullscreen,
If without target="_blank", clicking a link in full screen will correctly exit full screen and open the url in the same tab.
But if I have two tabs A,B opened and loaded. When tab A is fullscreen and I click a link with target="_blank", a new tab C will open and layer view will show the content of B....
Please find my patch and give me some hint :) ... thanks!
Flags: needinfo?(nchen)
Flags: needinfo?(esawin)
Assignee | ||
Comment 18•8 years ago
|
||
btw, please find the event sequence in the attachment. The event are the same for with/without fullscreen when target="_blank" The log is from here
https://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/Tabs.java#525
I've also called "Tabs.getInstance().getSelectedTab().getId()" in
https://searchfox.org/mozilla-central/source/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#1827
The tab is is also the latest. But layer view still shows the wrong content.
Please give me some advice. Thank you!
Comment 19•8 years ago
|
||
Comment on attachment 8826548 [details]
Bug 1319366 - When fullscreen, defer new tab selection until exiting fullscreen completed.
From the comments it looks like this is not the final patch yet? Just reflag me if needed. :)
Attachment #8826548 -
Flags: review?(s.kaspari)
Assignee | ||
Comment 20•8 years ago
|
||
Hi Jim
I just found that if I put a break point here in WebIDE
https://searchfox.org/mozilla-central/source/mobile/android/chrome/content/browser.js#3337
Just pause and continue to run...my patch will magically work....Could it related to Gecko rendering issue?
Cause I can't sense any where else could go wrong...
Thanks!
Assignee | ||
Comment 21•8 years ago
|
||
(In reply to Nevin Chen [:nechen] from comment #20)
> I just found that if I put a break point here in WebIDE
> https://searchfox.org/mozilla-central/source/mobile/android/chrome/content/
> browser.js#3337
Also I found If I put a break point here in WebIDE , the app will show correct content:
http://searchfox.org/mozilla-central/source/mobile/android/chrome/content/browser.js#4192
Both w/o the break point/pause will show me the same message,
But I can't find where this onLocationChange gets called so I can't debug further...
Comment 22•8 years ago
|
||
(In reply to Nevin Chen [:nechen] from comment #17)
> Please correct me if I'm wrong....
> I can't find when BrowserApp.selectTab is called while adding a new tab...
> so it might not be the cause?
You're right, it's not called by default, I just tried to picture a scenario that would describe what you see, assuming changed behavior with your patch.
> But I can't find where this onLocationChange gets called so I can't debug
> further...
browser.js registers as a listener for webprogress events and the webprogress manager calls "onLocationChange", "onStatusChange", etc., on the registered listeners.
Flags: needinfo?(esawin)
Comment 23•8 years ago
|
||
Sounds like a possible race between the UI thread and the Gecko thread. Have you tried your patch with the latest mozilla-central? Bug 1329268 just landed that tried to address some of the possible race conditions.
Flags: needinfo?(nchen)
Assignee | ||
Comment 24•8 years ago
|
||
I've pull the latest code. But it still didn't work.
I've check the Desktop code from :xidorn. He pointed out the desktop code register tab's open/close/select event and leave full screen mode when event happens.[1]
I think my patch is similar.
I even try to leave fullscreen mode here [2] using
BrowserApp.deck.addEventListener("TabOpen", (e) => { document.exitFullscreen();});
or add below code to [3]... but it still shows the last tab content.
case "TabOpen":
document.exitFullscreen();
break;
I think there's something wrong between [4] or [5] or [6]
Do you have time to look at this? Or Can you give me some advice ?
Thanks again!
[1] https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser-fullScreenAndPointerLock.js#445-447
[2] https://dxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#412
[3] https://dxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#6875
[4] https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.cpp#1209
[5] https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.cpp#1433
[6] https://dxr.mozilla.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.cpp#1463
Flags: needinfo?(nchen)
Comment 25•8 years ago
|
||
I'm not sure I understand entirely what's going on from the comments. Can you summarize the bug? So you start with a fullscreen page, then click a link, and then what happens?
Flags: needinfo?(nchen)
Updated•8 years ago
|
platform-rel: ? → -
Assignee | ||
Comment 26•8 years ago
|
||
Hi Jim
Sorry I should use permalink since the code changes everyday.
STR
1. Go to Google slide [1] and open a link.
2. The app will show correct content but didn't leave full screen mode.
Fix:
I tried to fix it by adding a fullscreen check whenever a new tab is created. So I add below lines in [2]
let openerWindow = (aFlags & Ci.nsIBrowserDOMWindow.OPEN_NO_OPENER) ? null : aOpener;
// =====add below lines========
if (documet.fullscreenElement){
document.exitFullscreen();
}
// =====add above lines========
let tab = BrowserApp.addTab(aURI ? aURI.spec : "about:blank", { flags: loadflags,
referrerURI: referrer,
external: isExternal,
parentId: parentId,
opener: openerWindow,
selected: true,
isPrivate: isPrivate,
pinned: pinned });
Fix Result:
App will leave fullscreen mode and display the navigation bar correctly, but it will show the last opened tab( e.g. tab A, B, C is opened. Click a link on tab A while A is in full screen mode, a new tab D will open, but the app shows the content of tab C)
I think my fix is correct because when I add a breakpoint and pause before I return newURI [3], the app will show correct content (tab D).
I suspect that the error happens before [4] cause if openURI returns too early(without breakpoint in [3]), the app will show wrong content. But I'm totally guessing cause I don't know any of the cpp code. So I need your wisdom to help me point out what could I did wrong or where can I know more about the cpp code(or I even look into the wrong file?)
[1] https://docs.google.com/presentation/d/145gnd-wT8kbmA9YuXaCWYB9LYaKEFM7WmIkKHzKgP6Y/edit#slide=id.p
[2] https://dxr.mozilla.org/mozilla-central/rev/3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/mobile/android/chrome/content/browser.js#3379
[3] https://dxr.mozilla.org/mozilla-central/rev/3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/mobile/android/chrome/content/browser.js#3381
[4] https://dxr.mozilla.org/mozilla-central/rev/3cedab21a7e65e6a1c4c2294ecfb5502575a46e3/toolkit/xre/nsNativeAppSupportWin.cpp#1463
Flags: needinfo?(nchen)
Comment 27•8 years ago
|
||
What happens if you call `document.exitFullscreen` after `BrowserApp.addTab` in [2]? Or add a delay? e.g. `setTimeout(() => document.exitFullscreen(), 0);`
Flags: needinfo?(nchen)
Assignee | ||
Comment 28•8 years ago
|
||
If I add setTimeout(() => document.exitFullscreen(), 0); It'll still show the last open tab.
but this time , adding the breaking point won't help.
Flags: needinfo?(nchen)
Assignee | ||
Comment 30•8 years ago
|
||
Yes. The result is the same even with breakponts.
Below is the test result
openURI: function browser_openURI(aURI, aOpener, aWhere, aFlags) {
let browser = this._getBrowser(aURI, aOpener, aWhere, aFlags); // [1]
setTimeout(() => { // [2][4]
document.exitFullscreen() // [7]
}, 5000); // [3]
return browser ? browser.contentWindow : null; // [5]
}, // [6]
[1] Showing a link and the test page in fullscreen mode (http://nevin-lab.appspot.com)
[2]~[6] Showing a blank layer view and black bar above it.
[7] navigation bar( Showing the content of previous opened page. (ToolbarDisplayLayout and status bar is back to normal)
Flags: needinfo?(nchen)
Assignee | ||
Comment 31•8 years ago
|
||
Yes. The result is the same even with breakponts.
Below is the test result
openURI: function browser_openURI(aURI, aOpener, aWhere, aFlags) {
let browser = this._getBrowser(aURI, aOpener, aWhere, aFlags); // [1]
setTimeout(() => { // [2][4]
document.exitFullscreen() // [7]
}, 5000); // [3]
return browser ? browser.contentWindow : null; // [5]
}, // [6]
[1] Showing a link and the test page in fullscreen mode (http://nevin-lab.appspot.com)
[2]~[6] Showing a blank layer view and black bar above it.
[7] Showing the content of previous opened page. (ToolbarDisplayLayout and status bar is back to normal)
Assignee | ||
Comment 32•8 years ago
|
||
I guess setTimeout is not helping here because it runs the anonymous function asynchrously. In above example, openURI returns before document.exitFullscreen() runs so it doesn't work. But if I call document.exitFullscreen() first and pause the breakpoint before openURI returns, it will work.
Comment 33•8 years ago
|
||
Actually BrowserApp.selectTab already has logic [1] for handling switching to another tab after exiting fullscreen. You should reuse that logic, and delay selecting the tab [2] when adding a new tab.
[1] http://searchfox.org/mozilla-central/rev/d20e4431d0cf40311afa797868bc5c58c54790a2/mobile/android/chrome/content/browser.js#1308
[2] http://searchfox.org/mozilla-central/rev/d20e4431d0cf40311afa797868bc5c58c54790a2/mobile/android/chrome/content/browser.js#1218
Flags: needinfo?(nchen)
Comment hidden (mozreview-request) |
Comment 35•8 years ago
|
||
mozreview-review |
Comment on attachment 8826548 [details]
Bug 1319366 - When fullscreen, defer new tab selection until exiting fullscreen completed.
https://reviewboard.mozilla.org/r/104506/#review110542
Not sure about the timeout. If it's really needed then reflag me.
I'll also add jchen as reviewer. He's been working with you on this patch, so he might have an opinion too. :)
::: mobile/android/chrome/content/browser.js:1217
(Diff revision 2)
> - if (selected)
> + if (selected) {
> + setTimeout(function(e) {
> - this.selectedTab = newTab;
> + this.selectedTab = newTab;
> + }, 500);
> + }
Do we really need this timeout here too? It looks like the fullscreen transition code will do the selection?
Attachment #8826548 -
Flags: review?(s.kaspari) → review-
Updated•8 years ago
|
Attachment #8826548 -
Flags: review?(nchen)
Comment 36•8 years ago
|
||
mozreview-review |
Comment on attachment 8826548 [details]
Bug 1319366 - When fullscreen, defer new tab selection until exiting fullscreen completed.
https://reviewboard.mozilla.org/r/104506/#review110678
::: mobile/android/chrome/content/browser.js:1218
(Diff revision 2)
> this._tabs.push(newTab);
> }
>
> let selected = "selected" in aParams ? aParams.selected : true;
> - if (selected)
> + if (selected) {
> + setTimeout(function(e) {
Yeah you don't need this timeout. I think the better fix is to set `aParams.selected` to `false` if we're in fullscreen mode, exit fullscreen, and then call `BrowserApp.selectTab` after we exit fullscreen mode.
::: mobile/android/chrome/content/browser.js:1233
(Diff revision 2)
>
> let evt = document.createEvent("UIEvents");
> evt.initUIEvent("TabOpen", true, false, window, null);
> newTab.browser.dispatchEvent(evt);
>
> + if (document.fullscreenElement) {
Use `selectedBrowser.contentDocument` instead of `document`.
Attachment #8826548 -
Flags: review?(nchen)
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 39•8 years ago
|
||
mozreview-review |
Comment on attachment 8826548 [details]
Bug 1319366 - When fullscreen, defer new tab selection until exiting fullscreen completed.
https://reviewboard.mozilla.org/r/104506/#review111618
::: mobile/android/chrome/content/browser.js:434
(Diff revision 4)
>
> if (this.fullscreenTransitionTab) {
> // Tab selection has changed during a fullscreen transition, handle it now.
> let tab = this.fullscreenTransitionTab;
> this.fullscreenTransitionTab = null;
> this._handleTabSelected(tab);
Don't need `this._handleTabSelected` anymore.
::: mobile/android/chrome/content/browser.js:1221
(Diff revision 4)
>
> let selected = "selected" in aParams ? aParams.selected : true;
> - if (selected)
> + if (selected) {
> + let doc = this.selectedBrowser.contentDocument;
> + if (doc.fullscreenElement) {
> + aParams.selected = false;
Split this and move this line to before `new Tab`, because `aParams.selected` is used there.
::: mobile/android/chrome/content/browser.js:1322
(Diff revision 4)
> let doc = this.selectedBrowser.contentDocument;
> if (doc.fullscreenElement) {
> // We'll finish the tab selection once the fullscreen transition has ended,
> // remember the new tab for this.
> this.fullscreenTransitionTab = aTab;
> doc.exitFullscreen();
Also, early return here. Otherwise you'll send the select tab message twice.
Attachment #8826548 -
Flags: review?(nchen)
Comment hidden (mozreview-request) |
Comment 41•8 years ago
|
||
mozreview-review |
Comment on attachment 8826548 [details]
Bug 1319366 - When fullscreen, defer new tab selection until exiting fullscreen completed.
https://reviewboard.mozilla.org/r/104506/#review112232
::: mobile/android/chrome/content/browser.js:434
(Diff revision 5)
>
> if (this.fullscreenTransitionTab) {
> // Tab selection has changed during a fullscreen transition, handle it now.
> let tab = this.fullscreenTransitionTab;
> this.fullscreenTransitionTab = null;
> - this._handleTabSelected(tab);
> + BrowserApp.selectTab(tab);
`this.selectTab(tab);`
::: mobile/android/chrome/content/browser.js:1218
(Diff revision 5)
> + }
> let newTab = new Tab(aURI, aParams);
>
> + if (this.selectedBrowser) {
> + let doc = this.selectedBrowser.contentDocument;
> + if (doc.fullscreenElement) {
Save the fullscreen state in a variable so you don't check this again.
Attachment #8826548 -
Flags: review?(nchen) → review+
Comment hidden (mozreview-request) |
Comment 43•8 years ago
|
||
mozreview-review |
Comment on attachment 8826548 [details]
Bug 1319366 - When fullscreen, defer new tab selection until exiting fullscreen completed.
https://reviewboard.mozilla.org/r/104506/#review112352
Attachment #8826548 -
Flags: review?(s.kaspari) → review+
Assignee | ||
Updated•8 years ago
|
Keywords: checkin-needed
Comment 44•8 years ago
|
||
Pushed by ryanvm@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/865aa70feec4
When fullscreen, defer new tab selection until exiting fullscreen completed. r=jchen,sebastian
Keywords: checkin-needed
Comment 45•8 years ago
|
||
bugherder |
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox54:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 54
Comment 46•8 years ago
|
||
Verified on Nightly 54.0a1(2017-02-16), with:
- Motorola Nexus 6 (Android 7.0)
- Huawei Honor 5X (Android 5.1.1).
Opening the new tab will not exit fullscreen, but I've found new issues caused by this:
Steps to reproduce:
1. While in fullscreen mode in the presentation, open the link.
2. Exit fullscreen and go to the tab opened from the presentation.
3. Open the tab drawer and select the presentation tab (or any other tab previously opened, with a functional page).
Expected results:
2. The page opened from the presentation's link should be loaded in a new tab.
3. The tab selected should show the page contents.
Actual results:
2. A blank page (about:blank) is opened instead of the actual linked page.
3. The tab selected is also blank white, showing the correct url of the page that is in it.
note: Any other tab containing about:blank, created by me, does not cause other tabs to open blank pages. Just the ones that open automatically from the steps I've described.
Updated•8 years ago
|
Comment 47•8 years ago
|
||
Assignee | ||
Comment 48•8 years ago
|
||
Hi Carsten
I forgot to add one line.
Would you please help back out this patch so I can submit another review?
Thank you!
Flags: needinfo?(cbook)
Comment 49•8 years ago
|
||
You can just land another patch on top of the existing patch.
Comment 50•8 years ago
|
||
(In reply to Nevin Chen [:nechen] from comment #48)
> Hi Carsten
> I forgot to add one line.
> Would you please help back out this patch so I can submit another review?
> Thank you!
Hey nevin,
a clean backout does not work anymore due to other changes i guess, would it possible to submit another patch ? thanks!
Flags: needinfo?(cbook)
Keywords: checkin-needed
Updated•8 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 51•8 years ago
|
||
Since bug 1341276 is landed and verified, I guess we can close this bug now?
Flags: needinfo?(oana.horvath)
Comment 52•8 years ago
|
||
Hi, I'm marking this as duplicate actually, based on the fact that the fix was made on bug 1341276. Thank you!
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Flags: needinfo?(oana.horvath)
Resolution: --- → DUPLICATE
Updated•7 years ago
|
Blocks: CVE-2017-7770
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•