After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 168933 - Have browser plugin
Have browser plugin
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
: 142363 170365 308254 321097 336242 345880 399946 440980 617562 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-03-02 00:16 UTC by Michael Osborne
Modified: 2015-08-25 12:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Osborne 2005-03-02 00:16:17 UTC
When trying to use mozplugger 1.7.1 to enable, evince can be made to appear
insidet he mozilla window, but it generates an error "unknown mime type".
Depending on the moxplugger config, another window (or more) can be generated as
well the last of which will actually be the file.
Comment 1 Marco Pesenti Gritti 2005-03-02 08:58:05 UTC
How is evince invoked by mozplugger? Arguments...
Comment 2 Bryan W Clark 2005-03-17 15:34:17 UTC
*** Bug 170365 has been marked as a duplicate of this bug. ***
Comment 3 Michael Osborne 2005-03-17 21:31:02 UTC
Evince 0.1.9 now seems to work in Firefox with mozplugger 1.7.1 with the
following line in mozpluggerrc:

noisy swallow(evince) : evince "$file"
Comment 4 Nickolay V. Shmyrev 2005-11-09 21:24:50 UTC
*** Bug 321097 has been marked as a duplicate of this bug. ***
Comment 5 Nickolay V. Shmyrev 2006-01-30 19:23:07 UTC
*** Bug 142363 has been marked as a duplicate of this bug. ***
Comment 6 Christian Persch 2006-03-27 19:46:53 UTC
*** Bug 308254 has been marked as a duplicate of this bug. ***
Comment 7 Christian Persch 2006-03-27 19:47:34 UTC
*** Bug 336242 has been marked as a duplicate of this bug. ***
Comment 8 Nickolay V. Shmyrev 2006-06-25 14:34:07 UTC
*** Bug 345880 has been marked as a duplicate of this bug. ***
Comment 9 Bastien Nocera 2006-08-14 19:14:37 UTC
Reopening to track the browser/Mozilla plugin (or did I miss a more recent bug?)
Comment 10 Diego Escalante Urrelo (not reading bugmail) 2006-12-04 19:09:00 UTC
What was the outcome of WSOP?
Comment 11 Pacho Ramos 2007-01-17 21:27:06 UTC
I think that an official evince plugin for brosers could be nice.

Thanks a lot
Comment 12 Nickolay V. Shmyrev 2007-01-23 21:20:03 UTC
*** Bug 399946 has been marked as a duplicate of this bug. ***
Comment 13 Bastien Nocera 2007-01-23 23:10:01 UTC
Confirming bug, as it should be.
Comment 14 sballeste 2007-03-02 10:11:18 UTC
(In reply to comment #11)
> I think that an official evince plugin for brosers could be nice.
> 
> Thanks a lot
>

Just a feature request about the ability to pass parameters in the URL from an html link to the browser plugin in order to add functionalities such open a document at a specific page, chapter or anchor.

Details of this whish is more described in this message of the gnome-list: http://mail.gnome.org/archives/gnome-list/2007-February/msg00041.html
Comment 15 Nickolay V. Shmyrev 2007-05-25 05:09:44 UTC
*** Bug 440980 has been marked as a duplicate of this bug. ***
Comment 16 Nickolay V. Shmyrev 2007-05-25 05:10:48 UTC
We aren't going to implement this. And evince work with mozplugger perfectly.
Comment 17 Maciej (Matthew) Piechotka 2007-11-23 18:39:05 UTC
(In reply to comment #16)
> We aren't going to implement this. And evince work with mozplugger perfectly.
> 

What with webkit?
Comment 18 Wouter Bolsterlee (uws) 2008-03-24 17:08:24 UTC
(In reply to comment #17)
> What with webkit?

Not going to change. Web browsers should open an Evince window instead of embedding it.
Comment 19 Valent Turkovic 2008-04-09 09:45:20 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > What with webkit?
> 
> Not going to change. Web browsers should open an Evince window instead of
> embedding it.
> 

Why? Why not let this options for users who find embedding more usable way of reading pdf files?
Comment 20 Dan Nicholson 2008-04-09 17:51:54 UTC
Would you accept a patch for a Mozilla plugin? This is something I've wanted to do for a long time, but I wouldn't want to waste my time.
Comment 21 Nickolay V. Shmyrev 2008-04-09 19:20:55 UTC
> Why? Why not let this options for users who find embedding more usable way of
reading pdf files

Because it's hard to create a good UI inside a browser. It will be a completely different application and no code will be shared. So the decision is to support standalone documents. GNOME was going to embed everything everywhere but later this idea became unsupported mainly because of UI issues.

> Would you accept a patch for a Mozilla plugin?

no, thanks.
Comment 22 Valent Turkovic 2008-04-10 09:11:18 UTC
Hi, in fedora you only need to do this in order to have pdf files open in your browser window:

yum install evince mozplugger

reference url: http://www.fedorafaq.org/#pdf
Comment 23 Lucian 2010-07-18 13:17:04 UTC
(In reply to comment #18)
> (In reply to comment #17)
> > What with webkit?
> 
> Not going to change. Web browsers should open an Evince window instead of
> embedding it.

This is simply not an option for some browsers. Sugar's Browse must either download the PDF or display it inline. We'd like to be able to display it inline, but since we're switching to webkit we can't use mozplugger. We'd have to do an ugly hack with evince.

If there was a NPAPI plugin, everything would be easier and cleaner. The issue about UI in a browser would be moot, as this UI would be custom-made to work in a browser. Would you accept such a contribution?
Comment 24 Christian Persch 2010-07-18 16:09:02 UTC
IMHO no.

The reason you put forward is bogus. What exactly would be the difference between the browser downloading the pdf and opening it in the pdf viewer (based on libevview, I suppose), and showing it in the browser in a 'custom-made' UI? There would be exactly zero difference, to the user. And since NPAPI is incredibly broken, from a developer standpoint, I'd go with the standalone app any time.
Comment 25 Lucian 2010-07-18 16:22:54 UTC
Then every browser that uses evince/poppler would have to implement yet another custom UI. 

I understand the concerns with NPAPI, but it's not exactly 'broken'. It works in virtually every browser. There is also Pepper, which will make things a lot better. For now, we're stuck with reimplementing pdf views in browsers, when most of us would be just fine with a generic NPAPI pdf viewer plugin.

It's simply the wrong attitude for the developer of a pdf viewer to say "Web browsers should open an Evince window instead of embedding it.".
Comment 26 Christian Persch 2010-07-18 17:01:07 UTC
(In reply to comment #25)
> Then every browser that uses evince/poppler would have to implement yet another
> custom UI. 

'every browser'? Sugar has more than one? (Or are you talking about the desktop?)

Also, this is exactly backwards: NO browser needs to implement yet another custom UI, since when pdfs are handled externally, there needs only be ONE UI for it, namely Evince (desktop) or, on sugar, its pdf viewer (I suppose there is one, since you need to show local pdfs?)

> I understand the concerns with NPAPI, but it's not exactly 'broken'. It works
> in virtually every browser.

Maybe if you've never tried writing a plugin; speaking as someone who HAS written NPAPI plugins, I maintain that it's broken.

> There is also Pepper, which will make things a lot
> better. For now, we're stuck with reimplementing pdf views in browsers, when
> most of us would be just fine with a generic NPAPI pdf viewer plugin.

There is absolutely no requirement to show pdfs in the browser; you can simply NOT implement it.

> It's simply the wrong attitude for the developer of a pdf viewer to say "Web
> browsers should open an Evince window instead of embedding it.".

I disagree. It's exactly the right attitude to say that embedding pdfs in the browser is broken, should never be done, and therefore we won't ever support it.
Comment 27 Lucian 2010-07-18 17:14:45 UTC
(In reply to comment #26)
> (In reply to comment #25)
> > Then every browser that uses evince/poppler would have to implement yet another
> > custom UI. 
> 
> 'every browser'? Sugar has more than one? (Or are you talking about the
> desktop?)
Every browser that uses gnome libs. At least Epiphany and Firefox come to mind.
> Also, this is exactly backwards: NO browser needs to implement yet another
> custom UI, since when pdfs are handled externally, there needs only be ONE UI
> for it, namely Evince (desktop) or, on sugar, its pdf viewer (I suppose there
> is one, since you need to show local pdfs?)
Users want and expect inline PDF viewing. PDFs are just documents, like HTML and it's inconvenient and confusing to many users to keep switching between applications. They're especially terrified of the 'mess' they have to clean up afterwards,
> > I understand the concerns with NPAPI, but it's not exactly 'broken'. It works
> > in virtually every browser.
> 
> Maybe if you've never tried writing a plugin; speaking as someone who HAS
> written NPAPI plugins, I maintain that it's broken.
I'll give you that, I've seen how painful it is.
> 
> > There is also Pepper, which will make things a lot
> > better. For now, we're stuck with reimplementing pdf views in browsers, when
> > most of us would be just fine with a generic NPAPI pdf viewer plugin.
> 
> There is absolutely no requirement to show pdfs in the browser; you can simply
> NOT implement it.
There is if your users require it. And they do if they work with a lot of PDFs.
> > It's simply the wrong attitude for the developer of a pdf viewer to say "Web
> > browsers should open an Evince window instead of embedding it.".
> 
> I disagree. It's exactly the right attitude to say that embedding pdfs in the
> browser is broken, should never be done, and therefore we won't ever support
> it.
Whether or not NPAPI is broken, I think you're about embedding PDFs in browsers in general, and so do users. Of course it's up to you to not support such a thing, but it makes things harder than they should be for browser devs.
Comment 28 Christian Persch 2010-07-18 17:52:14 UTC
(In reply to comment #27)
> > 'every browser'? Sugar has more than one? (Or are you talking about the
> > desktop?)
> Every browser that uses gnome libs. At least Epiphany and Firefox come to mind.

You started off saying you wanted this for sugar; so desktop browsers are irrelevant here. The evince developers have already, and repeatedly, rejected this request for the desktop.

> Users want and expect inline PDF viewing.
Esp. wrt. sugar, this is ridiculous. Sugar users are kids having no prior desktop computing experience; they don't 'expect' anything in this regard.

> They're especially terrified of the 'mess' they have to clean up
> afterwards,
I fail to see how closing a pdf view is any different from closing a browser view? (Whether that's a window, a tab, ...)

> Whether or not NPAPI is broken, I think you're about embedding PDFs in browsers
> in general, and so do users. Of course it's up to you to not support such a
> thing, but it makes things harder than they should be for browser devs.

You think a browser plugin is important, while the evince developers think a browser plugin is a bad idea; that's ok, we disagree. However note there is nothing stopping you from developing a NPAPI browser plugin (whether using libevview, or poppler directly) yourself, in your own source code repository --- but the evince developers aren't going to do the work for you.
Comment 29 Lucian 2010-07-18 19:20:56 UTC
(In reply to comment #28)
> You started off saying you wanted this for sugar; so desktop browsers are
> irrelevant here. The evince developers have already, and repeatedly, rejected
> this request for the desktop.
On the grounds that they know better when it comes to browser UI design.
> > Users want and expect inline PDF viewing.
> Esp. wrt. sugar, this is ridiculous. Sugar users are kids having no prior
> desktop computing experience; they don't 'expect' anything in this regard.
Again you assume things about downstreams. Sugar users are not just kids, many teachers use it too.
> > They're especially terrified of the 'mess' they have to clean up
> > afterwards,
> I fail to see how closing a pdf view is any different from closing a browser
> view? (Whether that's a window, a tab, ...)
It's about having extra files on disk, or in this case extra objects in the Journal. 
> > Whether or not NPAPI is broken, I think you're about embedding PDFs in browsers
> > in general, and so do users. Of course it's up to you to not support such a
> > thing, but it makes things harder than they should be for browser devs.
> 
> You think a browser plugin is important, while the evince developers think a
> browser plugin is a bad idea; that's ok, we disagree. However note there is
> nothing stopping you from developing a NPAPI browser plugin (whether using
> libevview, or poppler directly) yourself, in your own source code repository
> --- but the evince developers aren't going to do the work for you.
There have been offers of patches for evince, which were so vehemently refused. An effort supported by evince would have much better chance of survival.

I don't mean to tell you what you to do (I apologise if it came out that way), I'm just pleading to you (evince devs) to reconsider and mentioning a use case you may have not thought of.
Comment 30 André Klapper 2011-08-24 20:33:33 UTC
*** Bug 617562 has been marked as a duplicate of this bug. ***
Comment 31 Philippe Ferrucci 2015-08-25 11:41:33 UTC
Having the possibility to use evince in a browser would help spread the word about evince. It would help show evince to more people and hopefully get some donations.

Ma company software can display PDF files inside a window of the program. This is done by some "magic" installed by Acrobat Reader (I don't if it's a plugin but this thread seems to imply this).

As it's clear now that I won't be able to use evince for my customers, I'll have to stick to Acrobat reader. It means I'll have to install Acrobat on hundreds of computers. So it's the number of users that will never see evince.
Comment 32 Bastien Nocera 2015-08-25 12:04:48 UTC
(In reply to Philippe Ferrucci from comment #31)
> Having the possibility to use evince in a browser would help spread the word
> about evince.

A browser plugin was added in GNOME 3.14, changing the resolution to reflect that.